fixing i386 gas for 16-bit code

[erich@uruk.org]

Ian Lance Taylor <ian@cygnus.com> writes:

>    Date: Wed, 19 Jun 1996 00:41:40 -0500
>    From: VaX#n8 <vax@linkdead.paranoia.com>
> 
>    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, gas2@cygnus.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):  <erich@uruk.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.