gnupic: Re: [gnupic] PIC assembler technique question
Subject:
Re: [gnupic] PIC assembler technique question
From:
Bill Freeman ####@####.####
Date:
12 May 2005 21:32:38 +0100
Message-Id: <17027.48479.751314.110883@localhost.localdomain>
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.
> However, if we want to go the extra distance, we can have
> gpasm automatically instrument the code with "bank check assertions"
> that can be checked by gpsim. I've experimented a little with assertions
> already and think that we have the infrastructure on both the gpasm
> and gpsim side to support this. Of course, you'll only get the benefit
> of the check if you run the code through the simulator...
That's good!
Following in this vein, a static code coverage tool (or mode
of the simulator) that simply examined possible code flows could gain
a lot of this benefit without requiring you to create a stimulus file
that exercises all the code paths. (I've got a disassembler that I
wrote in Python that keeps track of RP bits and PCLATH so that it can
correctly resolve target symbols. It's got almost enough stuff in it
to do the flow analysis as is.)
> As far as the issue of breaking compatibility with MPASM, I don't think
> it'd be too hard to add a command line option like '--strict-MPASM' or
> something to enforce MPASM compatibility. But, we do run the risk of
> people passing around gpasm generated .cod files and complaining when
> they don't load in MPLAB...
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.)
Bill
