16-bit x86 status update

Here's a brief update on the current state of 16-bit x86 support...

The assembler has support for the .code16 directive and can happily
output 16-bit code. In pending patches¹ I have also added an
i386-*-*-code16 triple and fixed the disassembler to support 16-bit mode
(which was previously present, but could not be invoked and was fairly
broken). And added a '-m16' option to clang.

The main caveats to bear in mind for 16-bit code which was previously
built with gcc/gas are:

• We do not support the explicit 'data32' and 'addr32' prefixes in asm.

   The data32 prefix is almost never needed. If you use the correct
   suffix on an instruction (retl vs. retw, for example), then you
   should never need to use 'data32'.

   The addr32 prefix *is* needed by GNU binutils, because *even* when
   given an explicit address which is greater than 64KiB, it'll just
   give you a warning about truncation, and emit the instruction with
   a 16-bit addressing mode and the wrong address. LLVM doesn't do that,
   and is far happier to just use 32-bit addressing whenever it *might*
   need to. This means that we never really need an explicit addr32
   prefix to use 32-bit addressing in 16-bit mode. And also that our
   code tends to be larger.

• We do not support '.code16gcc'. This is a hack which emits code in
   16-bit mode but parses the input as if it's in 32-bit mode. So
   instructions which are ambiguous about their operand size will take
   their 32-bit form — a plain 'ret' will cause it to emit 'retl', etc.
   We *could* support this mode, but it would be moderately non-trivial.
   It would require the code emitter and the asm parser to maintain
   separate ideas of the mode. The fix for PR18303 makes that somewhat
   simpler, but still not entirely trivial. Alternatively we could add
   yet another mode bit for the *parser*, but I don't like that much.

• GCC allows the compilation of C code to 16-bit mode by using
   asm(".code16gcc") and also adding other flags such as
   -fno-unit-at-a-time to ensure that the .code16gcc really *is* the
   first thing the assembler sees. We don't support that horridness,
   and don't need it since clang can support '-m16'. We have also filed
   http://gcc.gnu.org/PR59672 to request the same in GCC.

I have been able to build the 16-bit startup code of the Linux kernel
with .code16 and 'clang -m16', and it works fine. I had to fix PR18303,
for which David Peixotto is working on a better fix, and I had to work
around PR3997 — which some people seem to be denying is a bug in the
first place, and claiming (wrongly) that GCC doesn't get it right
either. But both of those are pre-existing bugs, and Not My Fault™.

At this point, I'm not aware of any issues specifically with 16-bit
mode, other than the above. If anyone else wants to start testing it in
anger on real code, that would be useful...

Absolutely fantastic work, David. Thank you!

I just want to state that I hope we never implement the 16-bit Microsoft C++ ABI for -m16.

I just want to state that I nominate Reid to implement the 16-bit
Microsoft C++ ABI for -m16. He's doing such a wonderful job of the 32
and 64-bit versions!

Yours evilly.


LOL. :slight_smile:


I second that motion!

/me laughs evilly

But you won't have to worry about that. (At least, not yet... :wink: Right now, all -m16 supports (AFAICT) is a mode similar to .code16gcc: an ABI largely the same as i386, but any 32-bit instructions that get emitted have size prefixes. Nothing esoteric like far (i.e. segment:offset) pointers or "pascal" calling conventions. (And $DEITY have mercy if we have to implement huge pointers! :slight_smile:



In fact we've implemented no 16-bit ABI at all. This is really 32-bit
code, 32-bit object formats, 32-bit ABIs. Just expecting to run on a CPU
which happens to be in 16-bit mode and hence needs the 0x66 and 0x67
prefixes to be used. A lot.