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


Previous by date: 7 Sep 2005 19:20:05 +0100 Re: [gnupic] RE: gpasm question, Ben Dugan
Next by date: 7 Sep 2005 19:20:05 +0100 Re: [PIC] Mini Howto: Microchip tools under Linux with Wine, Chen Xiao Fan
Previous in thread:
Next in thread: 7 Sep 2005 19:20:05 +0100 Re: [gnupic] More than one #v(expression) in a single line of a macro, Ben Dugan

Subject: Re: [gnupic] More than one #v(expression) in a single line of a macro
From: Bill Freeman ####@####.####
Date: 7 Sep 2005 19:20:05 +0100
Message-Id: <17183.12407.902374.863427@localhost.localdomain>

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

Previous by date: 7 Sep 2005 19:20:05 +0100 Re: [gnupic] RE: gpasm question, Ben Dugan
Next by date: 7 Sep 2005 19:20:05 +0100 Re: [PIC] Mini Howto: Microchip tools under Linux with Wine, Chen Xiao Fan
Previous in thread:
Next in thread: 7 Sep 2005 19:20:05 +0100 Re: [gnupic] More than one #v(expression) in a single line of a macro, Ben Dugan


Powered by ezmlm-browse 0.20.