gnupic: gpasm chokes on #IF
Subject:
Re: gpasm chokes on #IF
From:
David Willmore ####@####.####
Date:
17 Apr 2004 19:52:10 +0100
Message-Id: <200404171851.i3HIpPn6021863@localhost.localdomain>
> 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
