Subject:
PIC assembler technique question
From:
Bill Freeman ####@####.####
Date:
12 May 2005 17:49:18 +0100
Message-Id: <17027.35082.408986.516576@localhost.localdomain>
First, my apologies if this is an old dead horse.
The question:
There's a feature of mpasm that is carried into gpasm that has
been annoying me for years. Specifically, the warning message that
tells me I'm using an address that's not in bank 0. Yes, I know that
I can turn that warning off. And I can get around it by masking the
address or subtracting the base of its bank to form its bank 0 alias.
I'd be delighted to hear of any "better" ways to get around
these warnings.
A pipe dream:
But the real trouble is that the messages make me want more.
My presumption is that they were intended to help me find when I have
mistakenly used an address not found in the current bank. (If there's
another purpose, I'd like to know that too.) But not only does it
complain when I use a non-bank 0 address even though I've set the bank
correctly (yeah, the assembler doesn't know that, see below), but it
fails to complain when I use a bank 0 address when the bank is set to
something else.
Things could be improved with somthing similar to the "assume"
feature of the common x86 assemblers. The assembler would keep a
notion of current bank, and complain when the bank of a specified
address differed. There would need to be special handling for
registers that appear in more than one bank, such as STATUS. The
special casing would have to be adjustable through the processor
specific includes, for example, to handle the aliasing of 0x70 through
0x7F in some, but not all, mid range devices.
I envision the notion of current bank being updated
automatically by recognizing the generation of the usual bank setting
instructions. (Such control could conceivably be extended to handling
some other operations that target the status register in circumstances
when it is possible to know the contents of W, but that doesn't get
you a lot of bang for the buck. Let the programmer use an explicit
assume when he does that.)
Any instruction can, of course, be a branch target. The bank
selected at the location of a goto or call may not match that at
another goto or call, or after a non branching instruction preceding
the label. In a single module assembly the assembler could
conceivably recognize the uncertainty and make the notion of current
bank "unknown". (Because it only takes one instruction to change one
RP bit, and that's how we often change between banks that differ in
only one RP bit, it's best to have 0, 1, and unknown states remembered
separately for each RP bit.) Labels would have to carry a notion of
bank (in an even more complex 0, 1, unknown, and unspecified fashion),
with checking of data address to bank match occurring in pass 2 only.
It is also necessary to recognize whether the label can be reached
without a branch, such as when the preceding instruction isn't a goto
or return, or when the instruction before that can skip. This is much
harder to do across separately assembled modules since it would
involve changing the object file format and updating the linker.
Simplest would be let the programmer provide an explicit
assume when necessary. It is tempting, however, to force him to do so
by making bank unknown when passing a label.
Note that Once there is a notion of current bank it also
becomes possible to have bank selection pseudo instructions or (if the
notion is testable) macros that only generate as many RP bit modifying
instructions as are actually required, rather than always generating
one for each RP bit.
In fact (though I, for one, don't want to go this far) it
becomes possible to automatically generate the RP modification
instructions necessary simply as a result of seeing the instruction
that uses a data address from other than the current bank. (This is
sort of the flavor of how assume is used in x86 assembler,
automatically generating segment register selection prefix bytes.)
An assembler that does these things is no longer fully mpasm
compatible, but the difference could probably be held to the addition
of one reserved word, and that could disabled or enabled by a command
line switch and/or environment variable. Then all mpasm source would
still be legal for the modified assembler. Current behavior is
essentially assume bank 0, with no automatic control of when and how
many RP bit changing instructions are generated.
There may be room for a similar scheme involving page
selection in instruction memory. I don't see a neat way of dealing
with IRP, however.
Final questions:
Is this totally bogus and or useless in some way that I'm
missing? If it's interesting, do you have opinions on syntax?
If I were to develop a set of patches for gpasm, would it likely
be accepted (eventually), or does the desire to stay faithful to
mpasm mean that we would be forked forever?
TIA, Bill
