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

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

Rask Ingemann Lambertsen wrote:
> 
>    I'm only now realizing that the back end Daniel Verkamp and you are
> working on is strictly for i386+ code. Did you try tweaking things like
> TARGET_HIMODE_MATH, TARGET_PARTIAL_REG_STALL and such in the existing i386
> back end?
> 

We haven't, no.  In fact, adding in 386+ instructions was later
modifications.  However, the application space we're targetting only
focus on 386 level (not 286, not 486) and size optimization.

Daniel spent some serious time early on messing with the i386 backend --
this was the original proposal -- but then decided that it was too
complicated; we adopted modifying DJ's backend as a fallback position.
Now, the *only* differences between 16-bit and 32-bit modes (on 32-bit
capable chips) are the relative cost of HImode vs SImode (in 16-bit
mode, HImode is by far cheaper in terms of code size) as well as the
totally different structure of the 16-bit addressing modes[1].

Adding 16-bit support to the existing backend would have the very nice
feature, of course, of benefitting from the huge amount of work that
goes into it, but it also means that destabilizing or slowing down the
existing code in any way is utterly unacceptable.  For doing a separate
backend, focusing only on code size optimizations makes a big difference
-- no need to do any kind of pipeline stall modelling, for example.

	-hpa


[1] for non-x86 folk: in 32-bit mode, an address is
base+index*scale+offset (with any part optional); any register is valid
for base and index.  In 16-bit mode, there is no scale, and only %bx and
%bp are valid for base, %si and %di for index.  As a result, in 16-bit
mode, %bx is usually call-clobbered whereas in 32-bit mode, %ebx is
call-saved.  It is also much harder to eliminate the frame pointer in
16-bit mode, since there is no %sp-based addressing at all.