Re: 16-bit i386 code support in GAS

[Ken Raeburn <raeburn@cygnus.com>]

   > (Sorry if this isn't the right place to ask this question;
   > I couldn't find any better address in the GAS documentation...)

Probably bug-gnu-utils is the best publicly advertised place.  The gas2
list at Cygnus is a less advertised one, intended mainly for developers.

   > How difficult would it be to add a feature to the i386 version
   > of GAS to allow it to generate 16-bit i386 code?  It seems like
   > it should be a trivial change - just add a directive that inverts
   > the decision of whether or not to add size prefixes to each
   > instruction, right?  Such a feature would make it possible to
   > avoid the icky old inverted-syntax, non-cross-compiling as86 and
   > ld86 programs for writing boot-related code in Mach (Hurd/Lites)
   > and Linux.
   >
   > So, could someone either add this feature, or point me to the
   > right parts of gas-i386 so I can do it myself, or tell me why
   > it isn't so simple?

No "decision" is being made, at least at run time.  The opcode table has
the prefixes already present for the 16-bit versions of instructions that
need them and absent for the 32-bit versions.  So "addw" would be a
two-byte instruction and "addl" a one-byte instruction.

One way to approach this might be to make the opcode table indicate which
operand size an instruction indicates, independently of the value of the
opcode itself, and add the prefix when a larger-than-byte operand size is
needed and it doesn't match the "current" mode.

Another is to check for 16-bit mode and strip off a size prefix if
present, or add one if the instruction would need one, using some kludge
to figure out whether an instruction's operands are 8- or 32-bit sized.

I'd like to see this work done (but cleanly!), for precisely the reasons
you mention.  Anyone doing kernel or stand-alone program development
currently has to have as86 and ld86 as well as the GNU tools for the
32-bit code.  That's just silly.

For consistent results, you'd probably want the disassembler to work in
16-bit mode too.  Un(?)fortunately, they use separate copies of the opcode
table, laid out in different formats.


I'd also like to have a general overhaul of the i386 back end done.  It's
got lots of other problems, especially some dealing with segment
registers.  I've been thinking about doing some of this work myself, but
if you've got a strong overall understanding of the quirks of the i386
instruction set, and a lot of spare time you want to donate, let me
know...