New back end ia16: 16-bit Intel x86

[Rask Ingemann Lambertsen]

On Tue, Jul 31, 2007 at 01:44:56PM -0400, Ross Ridge wrote:
> Michael Matz writes:
> > Blaeh, that's all ugly.  I actually think that ia16 is a reasonable name 
> >for this ISA, even though Rask just made it up.
> 
> I think "ia16" is an ugly backformation and being made up like this
> there's a risk of it conflicting with something else in the future.

   I did not make it up. Try asking Google for "Intel IA16" or "Intel
IA-16". At least one search result is 7 (seven) years old. It is also clear
from the search results that outside of Intel, IA16 or IA-16 means the
16-bit x86 family members i8086-i80286 and IA32 or IA-32 means x86 family
members starting with the i80386.

> >It's generating code for the 16 bit mode (which works on all the intel
> >CPUs) which for all practical measures is a different CPU architecture
> >than the same chip in 32bit or 64bit mode (it just happens to share some
> >mnemonics and insn encodings).
> 
> That's absurd.  By sharing the same instruction set and registers, for
> "all practical measures" it is the same CPU architecture.

   You know, over the years Intel (and for x86-64, AMD) fixed (or worked
around) many shortcomings of the i8086:

   1) Addressing modes, most notably the lack of sp relative addressing.
   2) Tight register constraints.
   3) Registers with no 8-bit move instructions.
   4) Lack (or prohibitive slowness) of useful instructions.

   There is also a huge difference in what optimized code looks like even
between the i80286 and the i80386. Compare the ia16 instruction cost tables
and ia16_rtx_cost() with the i386 ones and ix86_rtx_cost(). I borrowed much
for the i386 back here but the differences are too big for a merge.

> There's a
> bigger difference between 32-bit and 64-bit mode and GCC doesn't treat the
> x86_64 as a different architecture.

   The 32-bit and 64-bit modes are not all that different. The only big
differences are pc-relative addressing and zero extension of 32-bit
destination operands, the latter of which only requires extra instruction
patterns to utilize.

> Ideally a 16-bit IA-32 port should
> be merged into the i386 port, just like the x86_64 port.

   Q: How do I know you didn't discuss that with the i386 maintainers?
   A: Because you haven't started running for your life yet! :-)

   Notice a couple of things:

1) Different STORE_FLAG_VALUE.
2) Different register layout.
3) Much different optimization strategy.
4) Difference in insn patterns for addw, subw, andw, orw and xorw, where
ia16 tries hard to optimize 16-bit operations which are rare on i386.

   Now, x87 hardware floating point gives an easy upportunity for sharing
code between 16-bit and 32-bit modes[1], but with reg-stack.c already split
out from the i386 back end and 16-bit x87 not having all that many
instructions to write patterns for, I doubt the saving is worth the amount
of extra grot that a merge of ia16 and i386 would produce.

[1] 64-bit mode dropped the x87 style FPU.

-- 
Rask Ingemann Lambertsen