Re: Proposed addition to gpasm
"Scott Dattalo" <[email protected]>
| Newsgroups | gmane.comp.hardware.microcontrollers.gnupic |
|---|---|
| Message-ID | <[email protected]> |
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