It is strange masm doesn't support immediate real4 values.. I played a bit with creating the values with macros but had some problems.. It is possible though, with some very simple algorithms it can be done with a macro.
I managed to get the right value for the mantissa but not in all cases, and the algo I used does not round 'impossible' floating point values (like 3.2) the way masm does..
I'll give it another try someday, right now I've got too much to do.

Thomas
Posted on 2002-01-09 16:26:24 by Thomas
I thought about it too - that is why I came to the conclusion to patch masm. :grin:
Posted on 2002-01-09 16:38:07 by bitRAKE
So NaN are you saying that in the final assembled code that there is an opcode that will allow REAL4 immediate movement and that is what the:



mov dest, 12345678h


is tricking the assembler into using? I think the standard is C7 for dword immediate to mem.
Posted on 2002-01-09 16:40:13 by rdaneel
As for the specific op-codes, i dont have the intel specs infront of me (was tested on it last semester tho). If i remember correctly it is two bytes followed by the 32bit address, followed by the litteral 32 bit value.

So to me this is about 10 bytes long, and as the macro indicates, its backing up over the last 4 bytes and replace it with a different set of 1's and 0's (as per the actual REAL4 data).

Im not well versed in this neck of the woods, but i take it that when you do this:

FloatVal REAL4 3.14159

MASM does the dirty work of makeing 3.14159 into 4 bytes of binary info that adhears to some anchient standard invented by some crazy mathematicians for IBM in the early 80's. (( little history ))

Back on track, when your macro works, it realizes that real4 is only 4 bytes long, and simular to a DWORD. So it "uses" the opcode needed, but then instructs the assembler to "create" an litteral REAL4 value over the old 4 bytes.

I too agree that masm shouldnt need this macro, but asside from this, i see the real savings is not having to define the # as an equate or something elsewhere in the program.

Hope this helps..
:alright:
NaN
Posted on 2002-01-10 01:31:54 by NaN
The problem being: To pull off this wizardry you invalidate MASM's internal workings - the tables it figures what bytes to write to a file. Do not use ORG $-4 to back over code generated by MASM. If anyone wants proof, I'll round up some good examples of impossible to debug errors for you.
Posted on 2002-01-10 01:51:10 by bitRAKE
To: NAN


Thats an excellent link! I have them in PDF's but its too annoying to use as is (contents in 1 pdf, index in another, chapters unmarked in file name). Thanx!



Nan, I recently merged all the individual AoA16 files into one PDF and created a clickable table of contents (limited, but functional to the heads of the chapters only).

I created a windows installer for HLA 1.30 (recent) however it's a 12MB download becuase it's fully customizable and has all the downloadables and info from his website (I even printed some of the web pages into PDF and made them available)... I"ve been studying how HLA converts it's OOP into MASM before the compile... interesting stuff

Likely you aren't interested in the entire download, but if you want the AoA16 book let me know and I"ll send it your way...


Thanks,
_Shawn
Posted on 2002-01-10 02:31:53 by _Shawn
I would love to see it, umm I dont think my current E-mail will handle it (size ~ hotmail... you get it :) ), but you can send it to my robotic's related e-mail address:

roboflag@yahoo.com

( building a robot to play capture the flag on its own )

Likewise, after i finish all the hardware (about a two weeks more), i wouldnt mind touching base with you and seeing what you've managed to dig up.

Best of luck.
:alright:
NaN
Posted on 2002-01-10 07:10:22 by NaN

Readiosys,

Thats an excellent link! I have them in PDF's but its too annoying to use as is (contents in 1 pdf, index in another, chapters unmarked in file name). Thanx!


Glad it is useful to someone. :)
Someone posted the .doc version on the old board, but I don't remember the link... (I don't have them anymore).

Good bye ! :alright:
Posted on 2002-01-10 07:19:48 by JCP

I thought about it too - that is why I came to the conclusion to patch masm. :grin:


Masm loads all the files it reads in memory first so we could patch masm at that point, looking at some character sequence like $float(xxx) or something, converting the value to a dword and putting in back in (new) memory, masm will just see a dword.
I would give it a try if I just had enough time :rolleyes:

Thomas
Posted on 2002-01-10 15:51:27 by Thomas
If we gotta patch it, we gotta do it right. Actually make it support
normal float-constant immediate values. Dunno how hard it would
be to do, depends on how MASM does stuff internally... and it would
take some REing, which might make it a bit of a shady affair :).
Posted on 2002-01-11 00:38:29 by f0dder

If we gotta patch it, we gotta do it right. Actually make it support
normal float-constant immediate values. Dunno how hard it would
be to do, depends on how MASM does stuff internally... and it would
take some REing, which might make it a bit of a shady affair :).


Well it *does* know it's a real or bcd value, as the error message says so... But I think it's not easy to find that specific place where it decides to give an error..

Thomas
Posted on 2002-01-11 08:45:55 by Thomas
xrefs are your friend ;). But I don't really need it (for now at least),
so I can't be bothered to drag out the disassembler.
Posted on 2002-01-11 09:03:18 by f0dder
What version do we want to reverse? I've been browsing through 7.0 to see what is new, but most everyone has 6.14/5.
Posted on 2002-01-11 09:47:33 by bitRAKE
Well the latest version freely available to everyone.. I never saw 7.00 free for download but I believe 6.15.8803 is the latest version that came with the VC processor pack..
Posted on 2002-01-11 10:10:31 by Thomas