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

[Jan Hubicka <jh at suse dot cz>]

Hi,
> In the long term, I was thinking about -m16 compile flag, so we could 
> combine for example "-march=core2 -m16". Having -m16, the testsuite 
> would be run with RUNTESTFLAGS="--target_board=unix\{,-m16\}".
> 
> IIRC, linux boot code was just converted to plain C, and -m16 would 
> surely find some use there.

Linux boot code is using a gas feature that simply adds 32bit prefix
before instructions so 32bit code basically runs in 16bit mode.
This is probably quite satisfactory hack for them since code size
implications are small (and for modern CPUs that are no longer optimized
for 16bit moves, we would get faster result too, if that did matter at
all)

Running 16bit testsuite would require emulator in addition to a runtime
on modern systems since 64bit kernels won't do vm86. 
> 
> >>This way, all improvements to i386 backend would 
> >>automatically be available to ix86_16 backend. And since quite some 
> >>people look into i386 code, much more eyeballs will stare at your code 
> >>too, surely much more than if your code would be hidden in some obscure 
> >>directory.
> >>    
> >
> >   config/i386 is 75984 lines while config/ia16 is 6372 lines. There is a
> >risk that the ia16 bits drown in the i386 bits.
> >  
> Not when you put -m16 in the mix.
> 
> >>Please also remember that quite some of your 
> >>ideas/improvements based on your (not even released) backend  were added 
> >>to generic i386 backend, so both backends would benefit from code share. 
> >>    
> >
> >   In other words, you're trying to coax me into becoming an i386
> >maintainer. :-)
> >  
> 
> Well, this is not my call, but for sure I wouldn't oppose this decision.

It seems to me that whole discussin here is going wrong dirrection.
Discussing pros and cons of maintaining separate ia16 backend relative
to merged i386 implementation from ia16 only maintainer POV is probably
not going to bring anything good.  We need to optimizie for overall
maintainibility of the compiler as a whole.

So we need to figure out if the maintenance cost of having extra port we
need to keep up to date with changing interfaces of GCC is higher or
lower than maintenance cost of more complex i386 backend that is however
changing on faster.

I am still not terribly opposed to idea of separate 16bit backend
though. We have about 30 backends in the FSF tree, thus adding extra one
might have lower overall maintenance costs than complicating i386
backend code even further. At least in a sense that changes to middle
end breaking tha ia16 backend might be less frequent than changes to
middle end or i386 port breaking the -m16 feature.

It all assume that the community interested in ia16 port is willing to
maintain it or risk the fact that it will be obsoletted and removed in
future release of GCC.  I seem to be in a minority here however and plan
to merge 16bit code into i386.c seems good to me too.
> >
> >1a) ix86_fixup_binary_operands() / ia16_prepare_operands()
> >1b) ix86_binary_operator_ok() / ia16_arith_operands_p()
> >2a) ix86_cc_mode() / ia16_select_cc_mode()
> >2b) ix86_cc_modes_compatible() / ia16_cc_modes_compatible()
> >2c) ix86_expand_carry_flag_compare() looks interesting.
> >2d) ix86_expand_int_movcc() too, but I'd rather fix/extend if-conversion.
> >3a) PLUS/MINUS patterns which make use of the carry flag. For example the
> >ones I have proposed for fixing PR target/30315.
> >3b) Multiword PLUS/MINUS where both have room for improvement when it comes
> >to using the condition codes and i386 could use updating for lower-subreg.
> >4) x87 instructions.

I would a lot preffer full sharing of i386 backend over sharing just
couple of functions as suggested above. Many of those have not terribly
well defined semantics and depends a lot on i386 backend internals.
> >
> >   This may not look like a lot, but it centers around the only common
> >characteristics of the x86 family: The mod r/m fields of an instruction, 
> >the
> >effect that instructions have on the condition codes and the x87.
> >  
> 
> I have actually dig out an old Turbo Assembler Quick Reference Guide, 
> and (let's say more than) 90% of instructions are shared between 8086, 
> 80286 and 80386 (modulo r/m32 and imm32).

16bit to 32bit relation is different in the terms of encoding - 64bit
mode requires prefix for 64bit operations preferring 32bit operations
and this was designed to make instruction choice of 64bit code close to
32bit that makes MD file easier.

For 16bit operation, we would need to teach all promotion code to
preffer 16bit operations in this mode in addition to adding new set
patterns for 32bit double word operations.  This would contribute to
lesser than 90% overlap of instruction patterns.
> 
> >   Stage 3 starts in three weeks. How much is it realistic to achive before
> >then?
> >  
> If you choose to go with a separate backend, then it is due to global 
> maintainer to approve the port. To merge this backend into existing i386 
> backend, IMO it is not realistic to expect the merge to finish in the 
> 4.3 time frame.

We can however start with the cleanups and putting basic stuff.  The
x86-64 merge was done incrementally basically in the following order:
  1) i386.h configuration machinery was updated to expect word size
  different than 32.  We will probably need to do similar to expect
  integer size of 16bit
  2) register classes, constraint letters changes
  3) dwarf2, target macros and similar updates
  4) .md updates (I had all the new patterns originally in separate file
  and was moving them to i386.md file per type basis.  I guess you can
  partly do this too with your existing ia16 port)
  5) prologue/epilogue code and ABI bits

For 16bit support I would suggest pretty much similar scheme with step 0
added to clean up some of machinery we have - ie splitting out
ISA/target specific bits a bit and renaming some of controlling macros,
like TARGET_64BIT since we will have a 3 different main modes now.

If we do the changes incrementally, we can basically interrupt them as
the release cycle dictates possibly doing rest on a branch to be merged
shortly after stage1 re-opens.

Honza
> 
> Uros.