New back end ia16: 16-bit Intel x86
Rask Ingemann Lambertsen
rask@sygehus.dk
Tue Aug 7 01:29:00 GMT 2007
On Mon, Aug 06, 2007 at 04:21:24PM +0200, Uros Bizjak wrote:
> Hello!
>
> > What I mean when I ask you to mention benefits of merging ia16 into i386
> >is things like
> >
> > - will it make the compiler easier to maintain?
> > - will it make the compiler run faster?
> > - will it make the compiler use less memory?
> > - will it make the compiler produce better code?
> > - will it make the compiler easier to use?
> >
> >but feel free to add anything else that comes to your mind.
> >
>
> IMO, point 1 outweighs all other points.
Code quality matters a lot to me, otherwise I probably could have lived
with bcc.
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.
> The 16bit port is not something
> I'd consider heavily used port, so my main concern here would be a
> possible bitrot of the contributed code. To avoid this, I think that as
> much as possible code should be shared between much tested i386 and
> ix86_16 parts.
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.
> 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.
> 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. :-)
> 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?
> 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.
Stage 3 starts in three weeks. How much is it realistic to achive before
then?
--
Rask Ingemann Lambertsen
More information about the Gcc-patches
mailing list