This is the mail archive of the firstname.lastname@example.org mailing list for the gas2 project.
|Index Nav:||[Date Index] [Subject Index] [Author Index] [Thread Index]|
|Message Nav:||[Date Prev] [Date Next]||[Thread Prev] [Thread Next]|
Ian Lance Taylor <email@example.com> writes: > Date: Wed, 19 Jun 1996 00:41:40 -0500 > From: VaX#n8 <firstname.lastname@example.org> > > I was wondering if you know how hard it would be (for me) to fix gas > to create 16-bit code properly, especially in the case of SIB (scaled > indexed based) addressing modes on the i386. > > I don't know much about the i386 myself, so I'm CC'ing your note to > the gas developers list, email@example.com. Perhaps somebody on the > list will have some useful information. > > I have to hand code things like: > > movb 1(%si), %dh > > because it flubs the Mod-R/M byte. > > Another cool thing would be 8-bit offset addressing. Coding all this by > hand is hair-pulling material. It is so ugly I chose not to do it :) GAS already uses 8-bit offset addressing when possible. The "Intel Architecture" has two operand/address size modes for non-8-bit instructions, 16-bit or 32-bit. The actual opcodes are pretty much identical (except for the Mod-R/M and SIB bytes). 8-bit opcodes are the same no matter where they are used, and are a big win in terms of code density! If GAS didn't use them, the code would be much more bloated than it already is. The ".code16" directive that Bryan Ford wrote is pretty useful, with it's only real disadvantage being that the code produced is bloated with 32-bit address sizes and lots of operand/address size override prefixes (the prefixes are actually where a lot of the code bloat comes from). > I used to hand code stuff when I was a kid, but it's pretty horrifying > to think that anybody still has to do it. One of the tricks would be to use "objdump", having hacked the default address and operand size to 16-bit (a patch in included at the end of the message for this), to check yourself with. The disassembler already handles 16-bit Mod-R/M bytes. > I believe that there are some 16 bit i386 assemblers out there. Yeah, but they have other problems (like bad integration with 32-bit code... you can't really mix both in one file). If it considered worth the trouble, what needs to be changed is: -- Addition of 16-bit Mod-R/M byte tables. -- Addition of either some mode to force use of 16-bit Mod-R/M bytes instead of using the 32-bit plus address-size override (they are different enough that you can't always use the same indexing registers in the two different modes) or some code that knows how to fallback to the 32-bit cases intelligently. -- Addition of parsing logic to handle the 16-bit Mod-R/M bytes. -- Addition of real 16-bit addresses. The last part is a BIG problem. This requires that you have a 16-bit address relocation type in your executable/object file symbol table format. If configured for ELF and trying to output a relocatable object file, the assembler would go into fits (since ELF has only a 32-bit relocation type, I think). -- Erich Stefan Boleyn \_ E-mail (preferred): <firstname.lastname@example.org> Mad Genius wanna-be, CyberMuffin \__ (finger me for other stats) Web: http://www.uruk.org/~erich/ Motto: "I'll live forever or die trying" This is my home system, so I'm speaking only for myself, not for Intel.