Re: More than one #v(expression) in a single line of a macro

Ben Dugan writes about capabilities that he wishes gpasm macros had.


	I'm a macro lover myself.  And there are features that I wish
for that aren't there.  I'm not sure that enhancing macros is at the
top of any gpasm developers list.  (I'm making an effort toward
becoming one, but I'm not working on macros.)

	While gpasm macros may already be incompatible with MPASM,
some of the features I want would definitely lead to source files you
couldn't process with MPASM.  I suspect that we won't ever see much
beyond what it takes to ape MPASM (though that is probably a moving
target that might eventually satisfy us).

	Many of my issues could be addressed with a separate,
unrelated preprocessor, like m4 (or your favorite text transformation
scripting tool, such as perl, or my favorite, python).

	The major drawback of a text transformation preprocess is the
inability to control preprocessing based on values that the assembler
calculates.  When this bites you, it really bites, but many macros, if
not most, don't need information from the assembler.  Another large
subset can be written to produce, rather than just opcodes, suitable
if's, expressions, and even gpasm macro definitions as a work around.

	Finally, macros that define macros that redefine the first
macro (my head hurts) can do some surprising things.  While I haven't
tried it with gpasm (or MPASM), one of the classic hacks is a macro
that can be called repeatedly which accumulates the concatenation of
the arguments from all of the calls, which can later be inserted into
the source file as a single piece (through a macro invocation).  If I
can remember how this works or find a reference (it doesn't seem to be
in HAKMEM), I'll try it in gpasm (and MPASM) and report.

	But you might be able to do something with nested macros to
achieve the double #v action.

							Bill