gnupic: Re: [gnupic] gpasm macros/defines
Subject:
Re: [gnupic] gpasm macros/defines
From:
"David Barnett" ####@####.####
Date:
18 Oct 2006 22:56:10 +0100
Message-Id: <009401c6f300$1b6dd450$0401a8c0@barnett2>
I worked around my first problem just defining an extra symbol for each
macro.
With the other problem, I might be able to combine assembler variables and
#defines to work around it, but it seems like it'll be a hassle, not to
mention that the areas that need to change are already an eyesore. I tried
using the latest gputils source from CVS on it (which it looks like hasn't
changed in a while), and got the same results, so if it is a bug, it hasn't
been fixed yet.
Is there any good reason for not expanding macro parameters in define
statements contained within the macros? Or is there some kind of standard
that unambiguously defines the correct behavior?
David
----- Original Message -----
From: "David Barnett" ####@####.####
To: ####@####.####
Sent: Monday, October 16, 2006 2:43 PM
Subject: [gnupic] gpasm macros/defines
I've got some asm files that will assemble with MPASM but not with gpasm. I
think it's a result of stricter syntax rather than a bug, but I'll report it
just in case.
There are two problems with my code. The first and easiest to work around
is that in MPASM an #ifdef will treat macro names as defined labels, whereas
it looks like gpasm either treats them differently or processes macros after
#ifdef directives. I had been using this pattern a lot:
MY_MAC macro
endm
...
#ifdef MY_MAC
MY_MAC
#endif
but it causes problems in gpasm.
My second problem is a bit more convoluted. If you do a #define inside a
macro, the macro parameters in the definition will not be expanded:
START1 MACRO X
#define OP1 movlw X
ENDM
...
START1 5
OP1 ; gpasm reports "symbol not previously defined (X)."
My code had depended rather heavily on this specific ability, and I'm pretty
sure EQU will not help me (although EQU gives no errors in the same
situation). If it's appropriate, I can explain why I needed that
functionality and maybe someone can think of a workaround.
David
--------------------------------------------------------------------------------
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.408 / Virus Database: 268.13.4/476 - Release Date: 10/14/2006