Re: New back end ia16: 16-bit Intel x86

["H. Peter Anvin" <hpa@zytor.com>]

Rask Ingemann Lambertsen wrote:
> On Sat, Aug 18, 2007 at 06:32:20PM -0700, H. Peter Anvin wrote:
>> Rask Ingemann Lambertsen wrote:
>>>    It is not different in your case! You're targetting the i386, so you can
>>> use i386 addressing modes at just the cost of a 0x67 prefix:
>> Well, then you're effectively doing nothing other than the .code16gcc hack.
> 
>>>    Obviously you want to save the 0x67 prefix whenever possible; use
>>> "20(%bp)" instead of "20(%ebp)", for example.
> 
>    I think that counts as "other than the .code16gcc hack". Using 16-bit
> integers when possible does too. That's the opposite of what the i386 back
> end does.

As an interesting mental exercise, I tried to see if I could get the
i386 backend to emit 16-bit code.  It now produces code for some very
simple functions, but I find myself getting stuck pretty hard on the
fact that the i386 backend seems to assume pretty hard that
word == Pmode == the width of a hard register, which is not true when
one wants to use 32-bit registers but have 16-bit addressing.

Another problematic issue is that I haven't, at least, figured out any
way by which one can tell that only part of a register has been
clobbered by a function.  This means spilling 32-bit registers to the
stack every time, with extra 66 bytes.  This, in fact, was the
motivation for using HImode registers in DrV's port (there seems to be
some issues with that which we haven't figured out, but that's probably
just naïveté on our part.)

Anyway, it was worth a few hours to look into whether or not generating
16-bit code for 32-bit chips could be done without being overly invasive
on the i386 backend.  Not sure if this is a productive direction based
on what I've seen so far.

	-hpa