gas mailing list

[Jimmy Mason <jmason@austlcm.sps.mot.com>]

content-type:text/plain;charset=us-ascii
mime-version:1.0

Hello,

I posted recently to gnu.misc.discuss, but haven't had any luck in finding 
someone with similar experiences.  One person replied that you have a gas 
mailing list.  If that is true, I'd like to be added, and perhaps I could make 
some additions/suggestions to gas.  

My big problem is that our target processor has a 16-bit byte size.  It may be 
that I have overlooked some important detail when porting for this processor, 
but I have had several problems in the process which I have fixed using careful 
gas source modifications.  

Here's the article I posted.  If there's a more appropriate forum for such 
discussion, please let me know if I can join it or a similar mailing list.

Thanks,
Jimmy 

[forwarded article]

Hello,

My group is in the latter stages of porting the GNU compiler, assembler,
linker, binutils, bfd, and gdb packages to a new target.  I am responsible
for the assembler, linker, binutils, and bfd ports since they are all
intricately related.  (Oh yeah, this is my first time to try anything
of this magnitude and nature.  I am very impressed with the GNU packages
and hope to be a contributor someday.  BTW, where can I send bug questions?)

For the duration of the project, there has been this one issue that has
come back to haunt me, time and time again: the size of our target's
smallest addressable unit is 16 bits.

To the best of my knowledge, 'gas' (gnu assembler) doesn't support a
16-bit byte.  I was hoping gas would use the information in the
bfd/cpu-{target}.c source to decide what byte size to use, but it doesn't.

I get into trouble because when I store one 16-bit instruction. The
assembler treats it as 2 bytes, thereby stepping the value of the '.'
by two in the process.  Consequently, all labels (defined as .) are off
by a factor of two.

I compensate for all of this at the interface between the user and
parser and at the interface between the fragments and the coff file (the
format that I chose for historical reasons) during fixups and relocations,
mostly.

Here is an example:


.text

# ... skip 32 1-word instructions here

label1:
    bra  label1

.data
label2:
  .word (label2 + 2)

.end

When the assembler finds the 'label1' label, it gives it the byte offset
value of 64, because each of the first 32 instructions has consumed 16
bits, or 2 bytes on the host cpu.  When we compile the 'jmp' instruction,
we create a fixup for label1.  We know that we actually want to use the
value of 32 to compute the branch offset, so when we apply our fixes,
we divide the offset by two.

When the assembler parses in the '.word' directive, we have defined the
TC_PARSE_CONS_EXPRESSION macro so that we are responsible for parsing
the remainder of the line.  We read the line as an expression, then
examine it in case it's a symbol (as opposed to a constant).  In this
case, it is, and so we multiply the constant to add (ie. 2) by 2 to make
sure that when the 'label2' label is resolved to be twice what we want
it to be, and the gas internals add the 2 in, it has the correct
resolution.  We ultimately divide the whole thing by 2 when we apply the
fix later, though, so the 2 in unharmed.

Of course, I made a "temporary" quick hack in the listing routines to
divide all addresses by two before printing them out... There are several
other small adjustments, too.

I am hoping that someone else has had this problem before.  If so, I'd
appreciate to read about any interesting or helpful experiences you have
had while making gas work for you.  I feel miserable about all these
compensations I've had to make, and if there's a cleaner way to do it,
I'd like to know about it.

Thank you for your time.

Jimmy Mason

[end article]

--

Jimmy Mason                     IC Systems Design Engineer
jmason@austlcm.sps.mot.com      Motorola Wireless Division
(512)933-6169                   Austin, TX