gnupic: Re: [gnupic] More than one #v(expression) in a single line of a macro
Subject:
Re: [gnupic] More than one #v(expression) in a single line of a macro
From:
Ben Dugan ####@####.####
Date:
8 Sep 2005 14:01:50 +0100
Message-Id: <43203637.3010407@curdes.com>
Bill,
Thanks for your reply!
Bill Freeman wrote:
> 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.)
Well, yesterday I dug into the source code further and pretty much
decided its over my head at this stage.
>
> 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).
I am an m4 fan. But what I need goes beyond straight pre-processing,
because I'm looking to use labels in macros that would be calculated
during assembly.
> The major drawback of a text transformation preprocess is the
> inability to control preprocessing based on values that the assembler
> calculates.
Yes, and I think this is a problem in my immediate case.
> 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.
I think I have thought of a work-around for now. The code I am trying
to "port" to gpasm uses labels that are array-ish, as I said (label1_1,
label1_2, label2_1, label2_2, for example). This is kind of a logical
way to organize them from a programming standpoint given the use that
the program will be making of them. But there's no real reason these
labels can't just be label1, label2, label3, etc. I think they'll still
work just fine and be able to be both generated and referenced by macros
just as effectively. I'll try to change the asm code today to test this.
>
> 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.
My head hurts, too! I used recursive macros in m4 once by following an
example, and it worked. But I never really understood it well.
> But you might be able to do something with nested macros to
> achieve the double #v action.
Thanks again, I really appreciate your suggestions and thoughts.
Ben
