OPTION LITERALS in 32 bits

[johnsa]

Agreed Hutch, for now we've just kept the set quite small using the ones that I didn't think would really change much between 32/64. As always I welcome suggestions for inclusions etc.. the 32bit and 64bit macro library implementations are separated out, so we can easily have totally different implementations for each.

In the IFDEF case that JJ mentions I believe that would skip the custom implementation as it would already be defined.
1) Assuming the macros are the same, then there should be no problem.
2) Alternatively, you might have to disable to macro library -nomlib option.
3) We could add a built-in variable which gives the state of the macro library's inclusion and the IFDEF could be extended to check that  as well. ?

[jj2007]

In the IFDEF case that JJ mentions I believe that would skip the custom implementation as it would already be defined.
1) Assuming the macros are the same, then there should be no problem.
2) Alternatively, you might have to disable to macro library -nomlib option.
3) We could add a built-in variable which gives the state of the macro library's inclusion and the IFDEF could be extended to check that  as well. ?

1) right, but unrealistic - why build your own macro if there is one that works fine?
2) that would disable the whole UAsm macro lib
3) more precisely, let IFDEF believe that the built-in macros and constants are undefined (I can't see a case where that would cause problems)

This is certainly an exotic problem, but MASM has a known namespace that hasn't changed for decades. Extending that namespace with a user's macro library like the Masm32 macros.asm or MasmBasic is one thing, hard-coding new names into the assembler itself is a different thing.

[habran]

We can use now a new feature in UASM: UNDEF 8)
one example:
IFDEF FP4
 UNDEF FP4
ENDIF
and then change it as we want
however, it is not necessary in this case because you can write your own FP4 which will override the one from the macrolib. I have just given an example of UNDEF usage

[jj2007]

Undef is a nice feature, but my concern is a different one: There are moments where you ask "is the macro already defined?", and if the answer is yes, you use it, otherwise you define it and you launch an initialisation process. Anyway, don't bother with that, the -nomlib option will do the job.

[johnsa]

Undef is a nice feature, but my concern is a different one: There are moments where you ask "is the macro already defined?", and if the answer is yes, you use it, otherwise you define it and you launch an initialisation process. Anyway, don't bother with that, the -nomlib option will do the job.

Assuming we only include macros in the library that have extremely unique names or where the names are common-place have exactly the same result as masm32 familiar users would be expecting then that should be ok. There might be a way to include the macro library stuff in some sort of special scope/namespace so that it's always unique.. that was sort of where I wanted to get to with introducing namespace support in UASM, but even then that wouldn't be masm compatible no matter what namespace resolution operator we use.

[hutch--]

You may think I have an unusual view on this subject but if the macro engine can do what MASM in 32 bit does, then it may be useful but I would not cripple it to a 1990 design which masm up to the current 64 bit version has. Have MASM compatibility if you want it but be able to either turn it off OR have extra stuff that MASM never supported. You would not want to emulate MASM in 64 bit so there is no reason why you should restrict UASM to that age of design.

There are things that particularly irked me when setting up macros for 64 bit MASM, to make it more flexible you need to expand macros called by other macros inline rather than do them all before the calling macro. As far as which macros to use, it would be a lot simpler if it was left to which set of macros were used so you could have a MASM compatible set of macros, a more advanced and flexible set of macros and in 64 bit a UASM specific set of macros and none of these need to be embedded in the assembler itself. Leave it up to the punter using the assembler to pick which macros to use.

There is no problem providing macros for the punters to use as separate include files as this allows the punter to write as many of their own as they like but I suggest it is a mistake to embed a set of macros in the assembler itself.