gnupic: Re: [gnupic] gpasm macros/defines
Subject:
Re: [gnupic] gpasm macros/defines
From:
"Tamas Rudnai" ####@####.####
Date:
18 Nov 2006 02:14:54 +0000
Message-Id: <492f1420611171814g3f1223aeh2d08457381dc0a07@mail.gmail.com>
Hiya,
Maybe I just don't get it. #define handled by the preprocessor, while macro
by the compiler itself. So what happens here is that first preprocessor
idetifies that you defined OP1 as the string 'movlw X' then replaces the
source code where you write OP1 to that string. The compiler then will get
this input:
START1 MACRO X
ENDM
...
START1 5
movlw X ;
(#define removes as processed by the preprocessor, START1 is an empty macro,
and OP1 is the string replaced by the preprocessor)
You would need something like that:
#define OP1 START1 5
START1 MACRO X
movlw X
ENDM
...
OP1 ;
Tamas
On 11/17/06, David Barnett ####@####.#### wrote:
>
> ----- Original Message -----
> From: "David Barnett" ####@####.####
> To: ####@####.####
> Sent: Wednesday, October 18, 2006 3:55 PM
> Subject: Re: [gnupic] gpasm macros/defines
>
>
> > ...
> > With the other problem, I might be able to combine assembler variables
> and
> > #defines to work around it...
> >
> > 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?
>
> I thought I had a workaround for this define/arg expansion problem:
> START1 MACRO X
> #define OP1 movlw X
> ENDM
> ...
> START1 5
> OP1 ; gpasm reports "symbol not previously defined (X)."
> but it turns out there are problems with it, too. I'm getting kinda
> desperate for advice here. Scott, have you gotten in deep enough with
> gputils to know anything about this?
>
> David
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
>
>
--
unPIC -- The PIC Disassembler
http://unpic.sourceforge.net
