gnupic: Re: [gnupic] PIC assembler technique question
Subject:
Re: [gnupic] PIC assembler technique question
From:
Jerry Zdenek ####@####.####
Date:
17 May 2005 05:58:04 +0100
Message-Id: <428979CC.8090006@sarpeidon.net>
Bill Freeman wrote:
> Scott Dattalo writes:
> > Bill Freeman wrote:
> >
> > <*BIG* snip about gpasm/MPASM's bank stuff>
> >
> > The only problem with what you write is that the assumptions about the
> > current bank can be incorrect in certain circumstances. (Imagine a
> > function called from two different places; each with different RPx
> > settings).
>
> I think that's what I was getting at with all the prattling
> about adding to the symbol load for branch targets. But, yes, without
> some very fancy global evaluation the assumptions can get bonked. One
> nasty bit is if a subroutine returns with a different bank selected.
> Looking at some code that I have around, however, if bsf/bcf on STATUS
> gets tracked in linear flow, and I place assume directives at branch
> targets, even just at those that don't have a fall through path from
> above, the assumptions would be about perfect. If we add marking
> the state as unknown at each label, then I might get warnings that
> cry "wolf", most of the rest get picked up. Even if I have to add an
> explicit directive when I do something strange (like andwf STATUS,F),
> I'd find the warnings much more useful. Even calls to subroutine that
> affect bank selection can be wrapped, by the programmer, in a macro
> that correctly sets the assumption.
I've started putting the bank in the function names to keep it straight.
If the function doesn't specify, it's it's job to handle it. I'm
really tired of having turn on and off the bank warning. For my
programming sanity, I turn it off in sections that I know are in bank 1.
A better solution wild be great.
>
> Mmmm. Perhaps put the extra information in an ancillary file,
> or generate both a .cod file in the MPASM compatible format and a
> superset file, that includes the extra stuff, and that gpsim could
> learn to accept instead of .cod file. (.cod capability also remaining
> in gpsim, of course.)
Maybe a command line option to enforce MPASM compatibility, or the
reverse. Something like --strict-mplab (like GCC and the strict ansi flag)
