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

[Jan Hubicka <hubicka at ucw dot cz>]

>    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.

Being an i386 maintainer, I am not 100% convinced idea of merging the
ports is good either.  Not all your reasons seems valid:
- i386 backend itself has pretty good infrastructure for tunning a
  instruction choices. It is not problem at all to provide 286 cost
  table avoiding use of the expensive instructions.
  If there are good reasons, it is not problem to provide two rtx_cost
  implementations either.
- I don't see why we addw/subw/andw/orw/xorw needs to be significandly
  different on 16bit mode (we definitly can try hard to optimize them on
  i386 too even if benefit is little in 32bit mode).
- We can also handle relatively easily some of different codegen
  strategies, such as prologues/epilogues
- I am also not quite sure why you chosed different STORE_FLAG_VALUE.
  It is not big deal to have it varying in i386 port either, but I guess
  I need to check your implementation first.

What I am however concerned about it the effect of such a change on
32bit/64bit compiler - we would need to
- define new register classes (so we can deal with less symmetric
  addressing modes of 16bit mode).
  I also just noticed your port is having class for ax/al/ah registers,
  how this is implemented?
- define new alternatives of some common instructions.  In particular
  we would have patterns for most 32bit operations implemented via
  same mechanism as we do 64bit on ia-32 and 128bit on x86-64.
- we would probably end up complicating some of common move patterns
  further slowing down regalloc and reload.

I guess with some infrastructure this can be dealt with rather nicely
(we can, for example, put new patterns into separate sub .md file and
arrange it not be included in 32bit compiler when not targetting 16bit).

I guess we need to consider proc and const and also decide how ambitious
we want to be about the 16bit port - if we are just looking for a port
geenerating code for chips up to 286 perhaps with x87, we might get
better with separate port. (This is not that I would not want to care
about extra coplexity in i386...)

If we are interested in being able to produce good code, do scheduling
and support recent architectures (for people running MS-DOS on their
opteron/core2 machines), keeping ports merged is probably only choice.
This would imply some restructuralization of i386 backend puting generic
bits, ISA dependent bits and target ABI dependent bits separately, but
it would be a good thing to do anyway.

Honza
> 
>    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