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

[Rask Ingemann Lambertsen <rask@sygehus.dk>]

On Wed, Aug 01, 2007 at 12:38:25PM +0200, Jan Hubicka wrote:
> Being an i386 maintainer, I am not 100% convinced idea of merging the
> ports is good either.  Not all your reasons seems valid:

   I'm not saying it can't be done. I'm just mentioning the pros and cons
that come to my mind. In doing so, I'm coming up rather short on the pro
side. Every time you add one new if() clause, a new register class, a new
insn alternative, a new insn condition or perhaps a new insn patterns which
isn't relevant to your target, you make maintenance a bit harder. That can
be acceptable if you get something in return.

> - I am also not quite sure why you chosed different STORE_FLAG_VALUE.

   Because ia16 doesn't have the setcc instructions that i386 has. So while
1 is easiest on i386, -1 is easiest on ia16 for the supported cases.

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

   With the work that Joseph S. Meyers put into subreg_get_info() and its
HARD_REGNO_NREGS_*_PADDING macros for the PowerPC E500, it works nearly out
of the box, with just tree one-liners for reload. I've simply defined
HARD_REGNO_NREGS and HARD_REGNO_MODE_OK according to the registers available.

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

   Those people already have i686-djgpp.

-- 
Rask Ingemann Lambertsen