Subject:
Re: [gnupic] Proposed addition to gpasm
From:
Bill Freeman ####@####.####
Date:
1 Sep 2005 17:07:26 +0100
Message-Id: <17175.10322.155293.923626@localhost.localdomain>
Scott Dattalo writes:
> 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!
I, too, have a secret hope that MicroChip finds this topic
interesting. Many thinks for you kind comment.
> 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. ...
Certainly, relocatable mode operation is very desireable. This is
my first look into the gpasm code, however, and I wanted to take baby steps.
This provides functionality that I would have found useful in most of my
past PIC projects. It felt like a complete enough interim step. (Though
I'm now thinking that as it stands it shouldn't define __SUPPORTS_ASSUME
and assume in relocatable mode until it can offer functionality there.)
I think that it will be a while before I'm ready to tackle the
full blown relocatable situation. I'd have to take the time to
understand the COFF code and the linker. Though I'm currently "between"
software engineering jobs, that actually seems to increase the time
spend making ends meet, and gives me less time for contributory work.
A half step that I'm interested in making would be to check
freg addresses at assemble time if the address is absolute. This only
involves adding an argument to file_ok() and changing all of the calls
to pass a boolean to say whether the address is absolute. As I
mentioned in my mail to Peter, this is at least useful for the spfreg
symbols, which are frequently used and always absolute. Also, my only
relocatable projects so far have been so tight with allocation
restrictions (for example, I had to *know* what bank things would be
placed in or suffer reduced data rates) that I used relocation in the
code space only, and allocated my variables by hand, thus absolutely
at assemble time. Thus if I made this enhancement, the assume feature
would cover absolutely all of my PIC programming so far.
But, yes, I'd eventually like the assumptions and tests
carried into the linker. There is then also the possibility of
enhancing linker allocation strategy to automatically choose bank
assignment to correspond to the assumptions in force when a variable
is accessed.
> ...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).
Easy enough. Might it be better to allow BANKSEL to work as
the RBANKSEL macro does, possibly with a switch that has to be set to
allow it (probably using the assume directive)?
>
> 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.)
I totally agree. Still, I hope to do this incrementally. And
the simulator is yet another piece of code I'll have to crack open to
approach this.
> 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.
Yes, well, those errors are deliberate. They only occur under
--strict-mpasm. They're there to prove that the flag makes the assembler
work just like one that doesn't have the assume extensions. If some old
piece of code happened to use "assume" as a macro name, and you were
splitting a file into two of them or otherwise excerpting code, and wound
up with a file that didn't include the macro definition, you would want
the error.
Assume aware code can be backward compatible with assemblers
that don't implement assume by using "ifdef __SUPPORTS_ASSUME", as my
macros do. You'll note that the assume directives inside of the
macros don't cause errors at the macro invocations, even under
--strict-mpasm.
> 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.
Thanks. I do intend to keep working on it. However, while I
expect to be responsive about fixing bugs or small design defects in
the functionality that I've already provided, it will be a while
before I can extend that functionality.
Bill
