From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jimmy Mason To: gas2@cygnus.com Subject: gas mailing list Date: Wed, 20 Nov 1996 09:31:00 -0000 Message-id: <9611201731.AA01409@txbc.sps.mot.com> X-SW-Source: 1996/msg00110.html 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