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

[Uros Bizjak <ubizjak@gmail.com>]

Rask Ingemann Lambertsen wrote:

>> IMO, point 1 outweighs all other points.
>>     
>
>    Code quality matters a lot to me, otherwise I probably could have lived
> with bcc.
>   

Of course... I should add "... in addition to code quality.".
>    When it comes to maintaining a combined ia16/i386 back end, I'm not
> thrilled with the prospect of having to do a bootstrap and test cycle of
> i386 for each and every change to the ia16 parts. IMO this is a major point
> against a merge.
>   

[...]
>    It only helps a little. For example, powerpc-unknown-eabisim hasn't built
> for a few months now, despite sharing much code with targets such as
> powerpc64-unknown-linux-gnu, powerpc-ibm-aix5.2.0.0 and
> powerpc-apple-darwin8.5.0 which are built and tested daily.
>   
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.

>> 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.
>   
>> As an example, existing MIPS backend covers all targets from one code 
>> base, ranging from embedded 16bit to 64bit targets.
>>     
>
>    I'm no MIPS expert, but isn't MIPS16 mainly a compact instruction
> encoding, with a reduction in the available instructions and two-operand
> instructions to make the encoding fit into 16 bits?
>   

Hm, you are right there. The merge would more resemble i386 and x86_64 
merge (and for sure, there were reasons that these backends share the 
code. IMO, -m32 and -m64 are most important ones.)
>  
>   
>> If you choose this approach, I can help you to factor out common code to 
>> merge both backends.
>>     
>
>    Factoring out some common code sounds a lot better to me than an actual
> merge. There are some pieces of code which could probably be shared:
>
> 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.
>
>    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).

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

Uros.