gnupic: Re: [gnupic] gputils 0.13.6
Subject:
Re: [gnupic] gputils 0.13.6
From:
Dave Tweed ####@####.####
Date:
16 May 2008 15:24:03 -0000
Message-Id: <E1Jx1mT-0006DI-Ga@elasmtp-masked.atl.sa.earthlink.net>
Peter Stuge ####@####.#### wrote:
> On Fri, May 16, 2008 at 08:46:49AM -0400, George M. Gallant wrote:
> > A couple months ago a out out a feeler about local symbols. I
> > received 2 positive and 0 negative replies.
>
> Now 3 positive.
>
> > To me, local symbols are a must for large projects written in
> > assembler.
> > 1. No need to think up numerous names
> > 2. The scope of the label is local to the current routine.
> > 3. I use symbols of the for "@1" "@6" etc. Assigning the labels
> > sequentially makes following the code simpler.
> >
> > The downside is that the code is not usable by MPASM. As I am Linux
> > based and of the attitude that tools should not be limited to the
> > popular offering, this is not a problem for me.
>
> Agreed. I really like local symbols in macros.
>
> But nothing will stop developers from just not using local symbols if
> they want to stay compatible with MPASM.
>
> Perhaps gpasm could offer a preprocessor mode in the future, where it
> outputs processed assembly that MPASM always can build, but that's
> not required for adding local symbols I think.
I don't see any strong need for local labels outside of macros.
MPASM *does* support local labels in macros, BTW, and I think this is a
valuable feature.
I already use a source code preprocessor* for all my assembly-language
programming (not just PICs), which turns structured-programming keywords
such as if-else-endif and looping into the necessary jumps, skips and
labels (depending on the target architecture). I can even do a switch-like
structure as a one-pass loop with multiple conditional breaks in the loop
body.
99% of the time, I just need to make up a name for a subroutine, and all
labels within that subroutine are automatically generated for me, in the
form of the subroutine name with a number tacked onto the end. The numbers
increase monotonically in the generated code, so they're easy to find in a
debugging session. On those rare occasions where I do need to create a
label manually, I just use the subroutine name with a letter appended.
So, my vote would be to implement local labels for macros in the way that
MPASM does, and forget about the other kind of local labels.
* The preprocessor itself is a 600-line Perl script. It currently supports
ADSP-21xx, ADSP-BFxxx, PIC14/16, PIC18, dsPIC and TI T55xx. If you want
to see it, I could put it up on my website. There isn't much documentation
yet (Real Soon Now), but the code is reasonably well commented. For PICs,
it has a few quirks associated with Olin Lathrop's programming environment,
but that's easily fixed.
-- Dave Tweed
