Re: fixing i386 gas for 16-bit code

Re: fixing i386 gas for 16-bit code

[Ian Lance Taylor]

   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 :)

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.

I believe that there are some 16 bit i386 assemblers out there.

   Would I have to learn bfd?  It confused the heck outta me when I looked
   at the bfd source last time :-/

You shouldn't have to look at BFD for this sort of thing.

Ian

Re: fixing i386 gas for 16-bit code

[erich]

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.

Re: fixing i386 gas for 16-bit code

[erich]

Whoops!  I forgot to sent the hack for using objdump for 16-bit
disassembly (this is against binutils-2.6):

---------------------(diff for "opcodes/i386-dis.c")---------------------
--- i386-dis.c.orig     Thu Oct  5 19:18:18 1995
+++ i386-dis.c  Mon Apr 29 17:36:18 1996
@@ -1042,8 +1042,8 @@
     }

   /* these would be initialized to 0 if disassembling for 8086 or 286 */
-  dflag = 1;
-  aflag = 1;
+  dflag = 0;
+  aflag = 0;

   if (prefixes & PREFIX_DATA)
     dflag ^= 1;
---------------------(diff for "opcodes/i386-dis.c")---------------------

--
  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.

Re: fixing i386 gas for 16-bit code

[Bryan Ford]

>   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 don't think this would really be that difficult at all;
it's just work that I didn't have enough time or motivation to do
when I added the original partial support for 16-bit code.
Probably the only changes necessary should be in tc-i386.h and the
associated header files.

>   Would I have to learn bfd?  It confused the heck outta me when I looked
>   at the bfd source last time :-/
>
>You shouldn't have to look at BFD for this sort of thing.

True, although there is one separate but related problem, if you're using
ELF format...  The current ELF tools (maybe the i386 ELF format period,
I don't know) don't seem to support 16-bit relocations in object files;
the assembler just dies with an error.  This can usually be worked around
by either just using 32-bit addresses in cases in which relocations are
needed, or, in single-file "programs" such as boot blocks and such,
just writing the code so that the assembler does the relocating rather
than the linker - e.g., say "foo-_start" rather than just "foo".
However, fixing this properly presumably would involve BFD hacking.

				Bryan

Re: fixing i386 gas for 16-bit code

[Ian Lance Taylor]

   Date: Thu, 20 Jun 96 12:25:13 MDT
   From: Bryan Ford <baford@snake.cs.utah.edu>

   True, although there is one separate but related problem, if you're using
   ELF format...  The current ELF tools (maybe the i386 ELF format period,
   I don't know) don't seem to support 16-bit relocations in object files;
   the assembler just dies with an error.  This can usually be worked around
   by either just using 32-bit addresses in cases in which relocations are
   needed, or, in single-file "programs" such as boot blocks and such,
   just writing the code so that the assembler does the relocating rather
   than the linker - e.g., say "foo-_start" rather than just "foo".
   However, fixing this properly presumably would involve BFD hacking.

The BFD side of this is quite trivial: in elf32-i386.c, add an entry
to enum reloc_type, elf_howto_table, and elf_i386_reloc_type_lookup.

Of course, you then have to worry about the fact that your object
files violate the ELF ABI.

Ian