This is the mail archive of the
mailing list for the GCC project.
Re: New back end ia16: 16-bit Intel x86
- From: Rask Ingemann Lambertsen <rask at sygehus dot dk>
- To: Ross Ridge <rridge at csclub dot uwaterloo dot ca>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Wed, 1 Aug 2007 02:34:05 +0200
- Subject: Re: New back end ia16: 16-bit Intel x86
- References: <firstname.lastname@example.org>
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, 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.
 64-bit mode dropped the x87 style FPU.
Rask Ingemann Lambertsen