Does any one know where I can get clear info on how to make MACRO's in masm? I've never done it before. Maybe a how-to or syntax guide or something.
Posted on 2002-01-07 11:28:04 by rdaneel
A good start would be to read Chapter 9 (Google for MASM+Macro).
Posted on 2002-01-07 11:30:43 by bitRAKE
Are you talking about chapter 9 of AOA? I see macros section in Chapter 8 of AOA32.
Posted on 2002-01-07 11:36:59 by rdaneel
Hello !

It seems to be a division of AoA's website.

You will find all the needed information there...

Posted on 2002-01-07 11:43:29 by JCP

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!


Definitely give this a read thu, some basic examples, but its better if you have an idea in mind, and then see what MASM can do to help you. Feel free to ask more q's because some MACRO's are hard to understand their proper uses (build in ones anyways).

Best of luck.
Posted on 2002-01-07 13:19:20 by NaN
I'm trying to understand MACROs better so I can decipher what is going on in the Bizarre Creations OpenGL includes. For instance:

gl_movf MACRO dest,numb
mov dest,12345678h
ORG $-4
real4 numb

I'll read some and then ask more questions when I inevitebly get stuck. Thanks NaN.
Posted on 2002-01-07 14:30:07 by rdaneel
rdaneel, those macros will work most of the time, but you will get some errors that are almost impossible to debug. Using ORG $-4 within a macro to back over instructions that have been assembled is a bad thing in MASM. ORG is meant to be used with an immediate address to set the execution point in memory. $-4 means the current address minus four. This is a nice hack, but MASM isn't designed to do this and I have had serveral problems using such macros. This is just a friendly warning. :)
Posted on 2002-01-07 15:39:59 by bitRAKE
Agreed, this is a new one for me. As well you need to understand *how* ams is assembled to truely see what is happening...

The macro is designed to: move a litteral REAL4 (numb) number into a memory location (dest).

The trick to understanding this is:

mov dest, 12345678h

will be anywhere from 6 to 10 bytes long (depending if dest is a register or memory location), and the last 4 bytes will be (little endian notian):

.. .. .. 78 56 34 12 xx

The xx is where the assembler is left off at when it see's the $-4 to back up 4 bytes, and then write in the litteral REAL4 value overtop of the dummy bytes (and will be in little endian as well)

So long story short, the reason they have the:

mov dest, 12345678h

is to generate the proper "mov" opcode specific to the type of destination, and then place the reall type of data it wants to move instead of the 12345678h

Theres my analysis :) Thanx for posting it, never seen such "creativity" before..
Posted on 2002-01-08 03:12:39 by NaN
How come masm doesn't support real4 immediates? After all, that's
just one interpretation of 32bit of data... and since masm handles
REAL4 fine when defining data, it's not because the assembler lacks
floating-point support :).
Posted on 2002-01-08 03:18:48 by f0dder
Maybe because the x86 does all its floating point math on 80bit values. Doesn't it convert any fp number to 80bit for storage.
Posted on 2002-01-08 10:11:30 by rdaneel
rdaneel, you can still use 32 and 64bit float values (aka float and double).
It's just masm that's thickheaded, really :).
Posted on 2002-01-08 10:17:34 by f0dder
Agreed, its weird that masm doesnt support moving of real4 inmediate values.
Posted on 2002-01-08 10:45:54 by dxantos
MASM doesn't have any trouble handeling a real 4:

MyReal real4 0.0

mov ecx, MyReal

There it is moving the real4 pointer MyReal into a register. This compiles fine.

As I read it, the only thing this macro does in insert the pointer for numb into the instruction. This could be done a lot more directly:

gl_movf MACRO dest, numb
mov dest, numb

In fact, you don't even need the macro. Just do the substuitition yourself as you type the line.
Posted on 2002-01-08 11:36:47 by Ernie
Ernie, we were talking about immediate values, not memory values
(which it obviously handles fine). And I still can't see any reason
for not allowing immediate real4 values, except as a typical microsoft
"we know better than you" attitude :rolleyes:
Posted on 2002-01-08 19:47:49 by f0dder
There shouldn't be a problem with an immediate real4 to register. Its just a dword in length.

I think it's just a 'feature.'
Posted on 2002-01-08 22:29:33 by Ernie
Indeed there ought not to be problems with it, as it's just a dword in length.
But masm doesn't accept it, at least not directly. Lame. Perhaps there's
some type overriding you can do, though?

Oh well.
Posted on 2002-01-09 02:26:14 by f0dder
Couldn't you define a new type that is a union of DWORD,REAL4? That only works for memory access though, and you could just override with DWORD PTR. For the immediate case, a macro could be created that encode a FPU value. Might be better to patch MASM in this case.
Posted on 2002-01-09 09:47:04 by bitRAKE
I will now gracefully bow out of this thread since it is obvious that this issue is over my head. It might be best to stay away from Floating Point until my skills have been honed with straight up asm. I didn't even know 'movzx' existed until today. I think I'll just listen.

mov byte ptr [sideline], rdaneel
Posted on 2002-01-09 11:42:26 by rdaneel
Listen if you feel you must, but too many people do this by default, and what happens is people like f0dder keep talking to themselves :grin: (1100 and wha?? hehehe)

Really, if there is one thing i've noticed about this board is it takes people who are learning to insprire a convestation and any great depth. After all i dont think either f0dder or BitRake would have gotten into the "fray" with out your thoughts in the beginning :)

So please keep posting what you dont understand, or currious about!
Posted on 2002-01-09 15:32:35 by NaN
Some are the fuel and some are the fire - one doesn't exist without the other.
Posted on 2002-01-09 15:38:02 by bitRAKE