gnupic: Thread: gpasm chokes on #IF

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?

Cheers,
David

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: ####@####.####
> 

> 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.

I know. ;)  It's just that the documentation uses that term, so I
thought I'd use it, too. ;)  A little fiction never hurts.

> 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.

How do commercial PIC developers live with that?  I guess if it always
gets more inclusive, it's less risky, but I'd hate to have a new version
of the IDE (maybe necessary for *one* of the parts I'm using) break some
code for an older part.  That sure makes regression testing a bear.  You'd
need to keep a full regression environment around.  *shudder*

> I will retest mpasm and update gpasm's "preprocessor".

Optionally, I could poke the author with a sharp stick and tell him this
isn't a feature he should feel safe in relying on.  I think I'll do that
anyway.  This code is for the PIC-EL board (www.amqrp.org) which is part
of the ELMER-160 project.  A project that is trying to teach amateur radio
people how to program PICs.  As an example piece of code, we should probably
stick to proper, documented features of MPASM/MPLAB.  I'll go sharpen a
stick...

Thanks Craig.

Cheers,
David

On Sat, 2004-04-17 at 13:51, David Willmore wrote:
> > 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.
> 
> I know. ;)  It's just that the documentation uses that term, so I
> thought I'd use it, too. ;)  A little fiction never hurts.
> 
> > 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.
> 
> How do commercial PIC developers live with that?  I guess if it always
> gets more inclusive, it's less risky, but I'd hate to have a new version
> of the IDE (maybe necessary for *one* of the parts I'm using) break some
> code for an older part.  That sure makes regression testing a bear.  You'd
> need to keep a full regression environment around.  *shudder*
> 
> > I will retest mpasm and update gpasm's "preprocessor".
> 
> Optionally, I could poke the author with a sharp stick and tell him this
> isn't a feature he should feel safe in relying on.  I think I'll do that
> anyway.  This code is for the PIC-EL board (www.amqrp.org) which is part
> of the ELMER-160 project.  A project that is trying to teach amateur radio
> people how to program PICs.  As an example piece of code, we should probably
> stick to proper, documented features of MPASM/MPLAB.  I'll go sharpen a
> stick...
> 

I have changed gpasm.  I will commit it to cvs in a couple of hours.

> Thanks Craig.
> 
> Cheers,
> David
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
>