Re: [harmon@metronet.com: GNU GAS i386 16 bit]

[dj@ctron.com (DJ Delorie)]

> Adding a new object format can certainly be done.  It depends on what
> trickyness is in OMF.  If it doesn't require things that aren't
> already in BFD (such as shared library support), it would be
> straigtforward.  That's what BFD is for in the first place.  I also
> seem to recall there are gas ports to OMF floating around (pre-BFD).
> You might ask DJ Delorie (dj@ctron.com), if he isn't on the mailing
> list for thoughts, since he is closer to the MSDOS world than most of
> us UNIX-oids/GNU-oids are.

The OMF format is different from any Unix format, but EMX (gcc for
os/2) produces 32-bit OMF so it *can* be done.  I don't know what the
changes entail, though.

The biggest difference when dealing ith DOS OMF and 16-bit assembler
is something that's come up before - segments.  DOS has lots of them,
and gcc et al just don't support them very well.  With OMF and BFD,
you could treat segments like sections, so you could probably get
something that worked without having to re-engineer the BFD interface
itself.

Making gas support intel mixed assembler is a different story.  Little
of the i386 code will be reusable, since 16-bit opcodes have different
formats than the 32-bit ones (might as well be a whole new CPU).
Also, you'll need to keep track of operand and address size overrides,
which gas does for the i386 but will need to be extended.  Also, the
concept of default segments and use directives will be a new
experience for gas.

I think someone who has implemented support for a processor from
scratch should be able to add 16/32 OMF support without undue
difficulty, though.  Teaching gcc about it is a different story,
however.

gnuoids?