gnupic: gpasm chokes on #IF
Subject:
Re: gpasm chokes on #IF
From:
Craig Franklin ####@####.####
Date:
17 Apr 2004 19:39:20 +0100
Message-Id: <1082227131.1478.22.camel@r2d2>
On Thu, 2004-04-15 at 18:16, David Willmore wrote:
> >From looking at the manual, it's sort of unclear if there is
> a preprocessor invoked by default when using gpasm to assemble
> code. It does mention that #something will be handled by the
> prepreocessor (whitness #define), but #IF seems not to work.
>
> If I remove the #, then the IF .... ENDIF clauses work just
> fine.
>
> Is this just anohter of those MPASM will accept *anything* kind
> of situations?
>
> This is only an issue to me as it's someone elses code and every
> time he sends it to me I have to take out all of the #'s. I
> don't use MPLAB or any of the Windows programs, so I don't know
> if it's safe to recommend to the author to just take the #'s
> out. Is that functional over there in Windows land?
>
There is not a separate preprocessor. It is part of gpasm's lexer.
gpasm supports most of the documented features of mpasm. It also
supports some of the undocumented features.
AFAIK, the mpasm manual and the help in mplab only describe IF without
the #. #if is an undocumented extension. These extensions change from
release to release. For example, in the past #endif was only valid if
it started on column 1. #ifdef could start on any column. Now #endif
can be placed anywhere. This makes supporting gpasm a little bit of a
challenge. I remember testing #if a couple of years back and mpasm
didn't support it.
I will retest mpasm and update gpasm's "preprocessor".
> Cheers,
> David
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
>
