<div dir="ltr">I just want to state that I hope we never implement the 16-bit Microsoft C++ ABI for -m16.</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jan 14, 2014 at 12:00 PM, Jim Grosbach <span dir="ltr"><<a href="mailto:grosbach@apple.com" target="_blank">grosbach@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Absolutely fantastic work, David. Thank you!<br>
<div><div class="h5"><br>
On Jan 14, 2014, at 4:35 AM, David Woodhouse <<a href="mailto:dwmw2@infradead.org">dwmw2@infradead.org</a>> wrote:<br>
<br>
> Here's a brief update on the current state of 16-bit x86 support...<br>
><br>
> The assembler has support for the .code16 directive and can happily<br>
> output 16-bit code. In pending patches¹ I have also added an<br>
> i386-*-*-code16 triple and fixed the disassembler to support 16-bit mode<br>
> (which was previously present, but could not be invoked and was fairly<br>
> broken). And added a '-m16' option to clang.<br>
><br>
> The main caveats to bear in mind for 16-bit code which was previously<br>
> built with gcc/gas are:<br>
><br>
> • We do not support the explicit 'data32' and 'addr32' prefixes in asm.<br>
><br>
>   The data32 prefix is almost never needed. If you use the correct<br>
>   suffix on an instruction (retl vs. retw, for example), then you<br>
>   should never need to use 'data32'.<br>
><br>
>   The addr32 prefix *is* needed by GNU binutils, because *even* when<br>
>   given an explicit address which is greater than 64KiB, it'll just<br>
>   give you a warning about truncation, and emit the instruction with<br>
>   a 16-bit addressing mode and the wrong address. LLVM doesn't do that,<br>
>   and is far happier to just use 32-bit addressing whenever it *might*<br>
>   need to. This means that we never really need an explicit addr32<br>
>   prefix to use 32-bit addressing in 16-bit mode. And also that our<br>
>   code tends to be larger.<br>
><br>
> • We do not support '.code16gcc'. This is a hack which emits code in<br>
>   16-bit mode but parses the input as if it's in 32-bit mode. So<br>
>   instructions which are ambiguous about their operand size will take<br>
>   their 32-bit form — a plain 'ret' will cause it to emit 'retl', etc.<br>
>   We *could* support this mode, but it would be moderately non-trivial.<br>
>   It would require the code emitter and the asm parser to maintain<br>
>   separate ideas of the mode. The fix for PR18303 makes that somewhat<br>
>   simpler, but still not entirely trivial. Alternatively we could add<br>
>   yet another mode bit for the *parser*, but I don't like that much.<br>
><br>
> • GCC allows the compilation of C code to 16-bit mode by using<br>
>   asm(".code16gcc") and also adding other flags such as<br>
>   -fno-unit-at-a-time to ensure that the .code16gcc really *is* the<br>
>   first thing the assembler sees. We don't support that horridness,<br>
>   and don't need it since clang can support '-m16'. We have also filed<br>
>   <a href="http://gcc.gnu.org/PR59672" target="_blank">http://gcc.gnu.org/PR59672</a> to request the same in GCC.<br>
><br>
> I have been able to build the 16-bit startup code of the Linux kernel<br>
> with .code16 and 'clang -m16', and it works fine. I had to fix PR18303,<br>
> for which David Peixotto is working on a better fix, and I had to work<br>
> around PR3997 — which some people seem to be denying is a bug in the<br>
> first place, and claiming (wrongly) that GCC doesn't get it right<br>
> either. But both of those are pre-existing bugs, and Not My Fault™.<br>
><br>
> At this point, I'm not aware of any issues specifically with 16-bit<br>
> mode, other than the above. If anyone else wants to start testing it in<br>
> anger on real code, that would be useful...<br>
><br>
> --<br>
> David Woodhouse                            Open Source Technology Centre<br>
> <a href="mailto:David.Woodhouse@intel.com">David.Woodhouse@intel.com</a>                              Intel Corporation<br>
><br>
> ¹ <a href="http://git.infradead.org/users/dwmw2/llvm.git/summary/80bd3d9f" target="_blank">http://git.infradead.org/users/dwmw2/llvm.git/summary/80bd3d9f</a> and<br>
>  <a href="http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140113/201303.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140113/201303.html</a><br>
</div></div>> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</blockquote></div><br></div>