[LLVMdev] 16-bit x86 status update

[Reid Kleckner]

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


On Tue, Jan 14, 2014 at 12:00 PM, Jim Grosbach <grosbach at apple.com> wrote:

> Absolutely fantastic work, David. Thank you!
>
> On Jan 14, 2014, at 4:35 AM, David Woodhouse <dwmw2 at infradead.org> wrote:
>
> > 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...
> >
> > --
> > David Woodhouse                            Open Source Technology Centre
> > David.Woodhouse at intel.com                              Intel Corporation
> >
> > ¹ http://git.infradead.org/users/dwmw2/llvm.git/summary/80bd3d9f and
> >
> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140113/201303.html
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140114/96ccb57e/attachment.html>