[Nasm-devel] Preprocessor, and stuff...

[Frank K. <fbk...@co...>]

Cleo Saulnier wrote:

> I  will no longer mention the issue.

Okay, let's talk about Nasm! You contributed some proposed preprocessor 
changes back in July or August that have been "languishing" ever since. 
There are several other contributions - to preproc.c and others - in the 
same shape. This may be a worse problem than the rudderless list, and 
maybe something we can do something about.

As I recall, Andrew Zabolotny introduced "%xdefine", way back when. This 
is what the manual says about it:

;--------------
\S{xdefine} Enhancing %define: \I\c{%xidefine}\i\c{%xdefine}

To have a reference to an embedded single-line macro resolved at the
time that it is embedded, as opposed to when the calling macro is
expanded, you need a different mechanism to the one offered by
\c{%define}. The solution is to use \c{%xdefine}, or it's
\I{case sensitive}case-insensitive counterpart \c{%xidefine}.

Suppose you have the following code:

\c %define  isTrue  1
\c %define  isFalse isTrue
\c %define  isTrue  0
\c
\c val1:    db      isFalse
\c
\c %define  isTrue  1
\c
\c val2:    db      isFalse

In this case, \c{val1} is equal to 0, and \c{val2} is equal to 1.
This is because, when a single-line macro is defined using
\c{%define}, it is expanded only when it is called. As \c{isFalse}
expands to \c{isTrue}, the expansion will be the current value of
\c{isTrue}. The first time it is called that is 0, and the second
time it is 1.

If you wanted \c{isFalse} to expand to the value assigned to the
embedded macro \c{isTrue} at the time that \c{isFalse} was defined,
you need to change the above code to use \c{%xdefine}.

\c %xdefine isTrue  1
\c %xdefine isFalse isTrue
\c %xdefine isTrue  0
\c
\c val1:    db      isFalse
\c
\c %xdefine isTrue  1
\c
\c val2:    db      isFalse

Now, each time that \c{isFalse} is called, it expands to 1,
as that is what the embedded macro \c{isTrue} expanded to at
the time that \c{isFalse} was defined.
;--------------------------------------

Your code looks like it adds "%ydefine" and "%zdefine"... What would we 
need to say about *them*? Maybe something clearer than "%xdefine isFalse 
isTrue" can be devised to explain how this stuff works?

Anonymous Coward has a different approach to what I think is the same 
issue (I made him a developer, BTW - hope no one minds - he's the real 
"main contributor" lately, or one of 'em). Apparently, some of Andrew's 
changes in conjunction with adding "%xdefine" caused problems with some 
other things people wanted to do (?). Nickolay (you still around?) 
contributed a proposed preproc.c that's been in limbo, too. I think his 
code added some functionallity that it would be nice to have.

Stanislav forwarded a modified ndisasm.c from Massimo, asking if anyone 
could evaluate it. I took a quick look - he's rewritten the "horrible 
main loop that needs to be rewritten with an ax". Looks nicer, but I 
didn't figure out what problem it solves, if any. Anonymous Coward has 
sent us a patch to ndisasm in response to a request to get 
"more-source-code-like" output. Probably both of those should go in, if 
they don't conflict. David's "virtual extensions" to "-f obj" seem to 
compile and not cause any problems, but I don't know how to "try" 'em.

If we're waiting until "after 0.99" to make these changes, we could 
still try to come to some decision what we want to do... Don't look for 
much guidance from me on the macro stuff... I don't "wanna* "%define 
isTrue isFalse" :)

Best,
Frank