gnupic: Re: [gnupic] Proposed addition to gpasm
Subject:
Re: [gnupic] Proposed addition to gpasm
From:
"Scott Dattalo" ####@####.####
Date:
1 Sep 2005 14:47:56 +0100
Message-Id: <62583.67.113.28.97.1125582464.squirrel@67.113.28.97>
On Wed, 2005-08-31 at 09:59 -0400, Bill Freeman wrote:
> I have made an implementation of a scheme to make the "302"
> messages more useful. Those are the messages that caution you to be
> certain that the bank select bits are correct whenever you reference
> an address outside of bank 0 (my experience is primarily in the mid
> range PICs).
Bill,
I took a look at the tar ball and some of the code and am quite impressed!
I'd be interested to hear Craig's thoughts too. In fact, I'd be interested
to hear MicroChip's comments!
Here are a couple of suggestions that you may wish to consider. First, as
Peter suggests, the ASSUME directive should work in relocatable mode too.
There are a couple of issues that makes this challenging. Relocatable
variables are assigned absolute addresses at link time instead of assembly
time. This means the ASSUME directive has to work in conjunction with the
linker. Also, it probably means that ASSUME has to work more tightly with
the new RBANKSEL (and this probably means that RBANKSEL needs to be
implemented in gpasm's source and not as a macro).
Second, and I think this will be extremely useful, generate simulator
assertions to check the assumed bank bit settings. When simulated, the
assertions will verify that the bank bits are correct. As it stands, your
modifications to gpasm check the current bank of register when it's
accessed. This is the point at which the assertion can be inserted. Again,
relocatable mode makes this more challenging since the assertion can not
be created until after the variables have been assigned their final
addresses. (One caveat, simulator assertions currently do not work in
absolute mode.)
Finally, there needs to be a mechanism in place to ensure the .asm files
are backwards compatible with old versions of gpasm and (more importantly)
with MPASM. I see you've done this, but I also see that the ASSUME
directive caused assembly errors in one of your regression tests.
Bill, I really encourage you to continue working on this. I think this is
outstanding work and I'll try to support you however I can. Over the last
few years Craig has been maintaining/improving gpasm and gputils. But I
have write access to gputils CVS too! I'm going to refrain from modifying
gputils until we hear from Craig though. What might make sense is to
create a CVS branch that contain your enhancements. Then you can work
against this branch. Then at a later date we can merge the branch into the
main trunk.
Scott
