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

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

[Uros Bizjak]

Hello!

> On Wed, Aug 01, 2007 at 08:47:25AM -0400, Richard Kenner wrote:
> > > Could you give an outline of the benefits of merging it with the i386 port?
> > 
> > It's a subset of the registers and basically the same instruction set.
> > It has exactly the same relationship to the i386 port as the i386 port
> > has to the x86_64 port and that's merged.
>
>    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. 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. 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. 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. 
And considering the fact that every year processing power and memory 
(almost) doubles, I wouldn't care too much about the speed and memory 
consumption in this particular case as it is far less important than 
point 1, 4 and perhaps 5.

As an example, existing MIPS backend covers all targets from one code 
base, ranging from embedded 16bit to 64bit targets.

If you choose this approach, I can help you to factor out common code to 
merge both backends.

Thanks for this great contribution,
Uros.

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

[Rask Ingemann Lambertsen]

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

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

[Daniel Jacobowitz]

On Tue, Aug 07, 2007 at 03:29:33AM +0200, Rask Ingemann Lambertsen wrote:
> > 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?

That's correct.

-- 
Daniel Jacobowitz
CodeSourcery

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

[Uros Bizjak]

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.

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

[Jan Hubicka]

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.

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

[Mark Mitchell]

Jan Hubicka wrote:

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

Right.

I think that it would be much better to have 16-bit support as part of
the current x86 back end, both from our point of view as developers
(because there is a fair amount of commonality) and from the point of
view of users (because having different compilers for the same CPU is
odd, and some developers will want to develop both 16-bit and 32-bit code).

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

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

[Richard Kenner]

> I think that it would be much better to have 16-bit support as part of
> the current x86 back end, both from our point of view as developers
> (because there is a fair amount of commonality) and from the point of
> view of users (because having different compilers for the same CPU is
> odd, and some developers will want to develop both 16-bit and 32-bit code).

I agree completely.

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

[Rask Ingemann Lambertsen]

On Wed, Aug 08, 2007 at 02:21:42PM +0200, Jan Hubicka wrote:
> 
> 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.

   Right.

 1) Maintaining the target independent parts will take ever so
slightly more effort with a new back end. The dataflow merge on ia16, for
example, required the obvious regs_ever_live[] -> df_regs_ever_live()
change, nothing more, and something like that doesn't happen very often.

 2) The i386 back end will become more difficult to maintain after a merge.
It is a big back end already and there are not enough maintainers to keep
up. There will be more patches affecting i386 increasing review load.

 3) A 6500 line back end is much easier to maintain than a 76000 line one.

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

   A separate back end is a lot easier to obsolete and remove than one which
is merged into another.

> I seem to be in a minority here however and plan
> to merge 16bit code into i386.c seems good to me too.

   Looking at the few people who have commented on the issue, I notice that
among those who are not i386 maintainers, 100 % are in favour of a merge.
Among the i386 maintainers, 50 % are in favour and 50 % are against. I'll be
working on the 16-bit x86 code and is also against it.

   I'm disappointed to hear arguments along the lines of "-m16 looks cute"
in favour of a merge. From a user's point of view, you could just as well
say "gcc -b ia16-elf" as "gcc -m16" if it matters to you to use the same
front end binary.

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

   It is possible to define and document semantics. In many cases, it is
even thought of as a good idea.

-- 
Rask Ingemann Lambertsen

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

[Michael Matz]

Hi,

On Wed, 8 Aug 2007, Rask Ingemann Lambertsen wrote:

>    Looking at the few people who have commented on the issue, I notice 
> that among those who are not i386 maintainers, 100 % are in favour of a 
> merge. Among the i386 maintainers, 50 % are in favour and 50 % are 
> against. I'll be working on the 16-bit x86 code and is also against it.

FWIW, I'm not maintainer of anything, but I think you should have no 
obligation to merge it.  The pros of merging are not at all clear, the 
cons are conceivable, so you as author should have the last say.  We 
should be happy that someone is submitting a new backend, if he wants to 
have it separate for maintenance reasons or clarity, so be it, it can't 
have any effect on the other backends then.  If others see so many 
advantages of having it merged, then, well, they should do the work.


Ciao,
Michael.

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

[H.J. Lu]

On Wed, Aug 08, 2007 at 08:51:55PM +0200, Rask Ingemann Lambertsen wrote:
> 
>    I'm disappointed to hear arguments along the lines of "-m16 looks cute"
> in favour of a merge. From a user's point of view, you could just as well
> say "gcc -b ia16-elf" as "gcc -m16" if it matters to you to use the same
> front end binary.

I don't see -m16 work natively on Linux even with a merged x86 backend
since 16bit run-time enviroment is totall different.  It is most likely
to be built as a cross compiler for a different target.

My main concern is the new processsor support. I don't know if ia16
will need to suport new processsor and where it will come from if
it is needed.

On the other hand, if merging with x86 will force x86 backend to be
modular and flexible, it is a good thing since x86 backend has to
support so many different calling conventions and there may be more
on the way. Cleanup x86 backend with ia16 merge is a good long term
investment.


H.J.

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

[DJ Delorie]

> I don't see -m16 work natively on Linux even with a merged x86
> backend

Worse, I imagine people confusing -m16 meaning "32 bit code in 16 bit
mode" and -m16 meaning "16 bit code on a 16 bit chip".

I think the first could go in the i386 backend, if it isn't already,
but the second is almost a completely different kind of chip.

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

[Jan Hubicka]

> 
>    Looking at the few people who have commented on the issue, I notice that
> among those who are not i386 maintainers, 100 % are in favour of a merge.
> Among the i386 maintainers, 50 % are in favour and 50 % are against. I'll be
> working on the 16-bit x86 code and is also against it.

Well, given that there seems to be mostly consensus about merging the
backend, I guess it is way to go. If you are interested to do the job, I
will be happy to review the incremental patches (at least till 22nd when
I am leaving for 8 days).
I would propose the plan of getting initial changes into mainline before
stage2 closes and continuing on the branch.  Definitly the changes for
branch can be reviewed making merge at stage1 easy.
> 
> > > >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.
> 
>    It is possible to define and document semantics. In many cases, it is
> even thought of as a good idea.

We would have to stabilize fair amount of i386 internal interfaces (ie
pattern names for various instructions, macros defined and such) to get
the common expanders working.  This does not seem terribly practical
even if it is certainly doable.

Honza
> 
> -- 
> Rask Ingemann Lambertsen

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

[Rask Ingemann Lambertsen]

On Thu, Aug 09, 2007 at 11:33:09AM +0200, Jan Hubicka wrote:

> I would propose the plan of getting initial changes into mainline before
> stage2 closes and continuing on the branch.  Definitly the changes for
> branch can be reviewed making merge at stage1 easy.

   Although Uros and you can approve a merge, I'd like to hear from the SC
that they think it is a good idea to go down that path.

   I don't think a merge is likely to make much progress before stage2
closes. For example, I'll have to find a solution to the difference in the
register layout, as otherwise a merge is a non-starter.

-- 
Rask Ingemann Lambertsen

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

[DJ Delorie]

Jan Hubicka <jh@suse.cz> writes:

> > 
> >    Looking at the few people who have commented on the issue, I
> > notice that among those who are not i386 maintainers, 100 % are in
> > favour of a merge.  Among the i386 maintainers, 50 % are in favour
> > and 50 % are against. I'll be working on the 16-bit x86 code and
> > is also against it.
> 
> Well, given that there seems to be mostly consensus about merging the
> backend,

I don't see a consensus at all.  Half the i386 maintainers and the
ia16 contributor are AGAINST a merge.  Me, I'm against it too -
they're almost completely different "chips", and there's great
potential for confusion between a pure 16 bit environment and 32 bit
code running in a 16 bit mode.

I say keep it separate.

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

[Rask Ingemann Lambertsen]

On Tue, Aug 07, 2007 at 10:03:09PM +0200, Uros Bizjak wrote:
> Rask Ingemann Lambertsen wrote:
> 
> [...]
> >   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\}".
 
   When would "-march=core2 -m16" make any sort of sense? Note that you
won't be able to configure for e.g. i686-pc-linux-gnu and run the test suite
with "--target_board=unix\{,-m16\}" because -m32 uses glibc and -m16 uses
newlib.

> IIRC, linux boot code was just converted to plain C, and -m16 would 
> surely find some use there.

   The linux boot code compiles into 32-bit, i386+ code using the unmodified
i386 back end. That it runs in a code segment where the default data and
address sizes are 16 bits just means that it needs a lot of 0x66 and 0x67
prefixes, but that's handled entirely by GAS. If you want to help the linux
people here, implement an option to reliably output a ".code16gcc" directive
at the beginning of the asm file.

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

mov/div/add/sub/or/xor/and/push/pop,jmp,jCC is shared,
shift/rotate[1],mul,sCC,mov[zs]MN,lea,cmov isn't. It's not like 90%.
Addressing modes are also significantly different.

[1] The detail here is that while the assembler syntax, permitted operands
and such are similiar, these instructions are usually prohibitively
expensive on anything less than an i80386.

-- 
Rask Ingemann Lambertsen

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

[H. Peter Anvin]

Rask Ingemann Lambertsen wrote:
> 
>    The linux boot code compiles into 32-bit, i386+ code using the unmodified
> i386 back end. That it runs in a code segment where the default data and
> address sizes are 16 bits just means that it needs a lot of 0x66 and 0x67
> prefixes, but that's handled entirely by GAS. If you want to help the linux
> people here, implement an option to reliably output a ".code16gcc" directive
> at the beginning of the asm file.
> 

[Sorry for jumping in late]

There is a fair bit of code bloat as a result, though.  I have been 
mentoring and working with a GSoC student, Daniel Verkamp, in putting 
out a different 16-bit x86 backend based on old work by DJ Delorie. 
That backend just got to the point where we can compare code sizes; the 
code appears 10-20% smaller than the i386 backend with .code16gcc and 
-Os.  Although that is less than I would have expected, that is without 
any optimizations whatsoever and so the resulting code is actually quite 
  poor.

16-bit code still has its niches (boot loaders, option ROMs) and they're 
all rather small :)  So code size matters a great deal.  .code16gcc also 
has the problem that if you ever run into something that corrupts the 
upper half of the stack pointer you have a problem.  I haven't ever seen 
that in the field, though (as long as you watch out for %sp == 0.)

	-hpa

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

[Rask Ingemann Lambertsen]

On Fri, Aug 17, 2007 at 03:36:34PM -0700, H. Peter Anvin wrote:
> Rask Ingemann Lambertsen wrote:
> >
> >   The linux boot code compiles into 32-bit, i386+ code using the 
> >   unmodified
> >i386 back end. That it runs in a code segment where the default data and
> >address sizes are 16 bits just means that it needs a lot of 0x66 and 0x67
> >prefixes, but that's handled entirely by GAS. If you want to help the linux
> >people here, implement an option to reliably output a ".code16gcc" 
> >directive
> >at the beginning of the asm file.
> 
> There is a fair bit of code bloat as a result, though.

   That's what I said, isn't it?

>  I have been 
> mentoring and working with a GSoC student, Daniel Verkamp, in putting 
> out a different 16-bit x86 backend based on old work by DJ Delorie. 

   IMHO, a 16-bit x86 back end is not a very nice GSoC project. More like
something you can break your neck on.

> That backend just got to the point where we can compare code sizes; the 
> code appears 10-20% smaller than the i386 backend with .code16gcc and 
> -Os.  Although that is less than I would have expected, that is without 
> any optimizations whatsoever and so the resulting code is actually quite 
>  poor.

   You could probably save at least as much by using 16-bit integers, thus
avoiding the 0x66 prefixes.

-- 
Rask Ingemann Lambertsen

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

[H. Peter Anvin]

Rask Ingemann Lambertsen wrote:
> 
>> That backend just got to the point where we can compare code sizes; the 
>> code appears 10-20% smaller than the i386 backend with .code16gcc and 
>> -Os.  Although that is less than I would have expected, that is without 
>> any optimizations whatsoever and so the resulting code is actually quite 
>>  poor.
> 
>    You could probably save at least as much by using 16-bit integers, thus
> avoiding the 0x66 prefixes.
> 

Yes, with 16-bit integers it reduced the code size even further.

	-hpa

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

[Rask Ingemann Lambertsen]

On Fri, Aug 17, 2007 at 10:33:19PM -0700, H. Peter Anvin wrote:
> Rask Ingemann Lambertsen wrote:
> > 
> > H. Peter Anvin wrote:
> >
> >> That backend just got to the point where we can compare code sizes; the 
> >> code appears 10-20% smaller than the i386 backend with .code16gcc and 
> >> -Os.  Although that is less than I would have expected, that is without 
> >> any optimizations whatsoever and so the resulting code is actually quite 
> >>  poor.
> > 
> >    You could probably save at least as much by using 16-bit integers, thus
> > avoiding the 0x66 prefixes.
> 
> Yes, with 16-bit integers it reduced the code size even further.

   I'm only now realizing that the back end Daniel Verkamp and you are
working on is strictly for i386+ code. Did you try tweaking things like
TARGET_HIMODE_MATH, TARGET_PARTIAL_REG_STALL and such in the existing i386
back end?

-- 
Rask Ingemann Lambertsen

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

[H. Peter Anvin]

Rask Ingemann Lambertsen wrote:
> 
>    I'm only now realizing that the back end Daniel Verkamp and you are
> working on is strictly for i386+ code. Did you try tweaking things like
> TARGET_HIMODE_MATH, TARGET_PARTIAL_REG_STALL and such in the existing i386
> back end?
> 

We haven't, no.  In fact, adding in 386+ instructions was later
modifications.  However, the application space we're targetting only
focus on 386 level (not 286, not 486) and size optimization.

Daniel spent some serious time early on messing with the i386 backend --
this was the original proposal -- but then decided that it was too
complicated; we adopted modifying DJ's backend as a fallback position.
Now, the *only* differences between 16-bit and 32-bit modes (on 32-bit
capable chips) are the relative cost of HImode vs SImode (in 16-bit
mode, HImode is by far cheaper in terms of code size) as well as the
totally different structure of the 16-bit addressing modes[1].

Adding 16-bit support to the existing backend would have the very nice
feature, of course, of benefitting from the huge amount of work that
goes into it, but it also means that destabilizing or slowing down the
existing code in any way is utterly unacceptable.  For doing a separate
backend, focusing only on code size optimizations makes a big difference
-- no need to do any kind of pipeline stall modelling, for example.

	-hpa


[1] for non-x86 folk: in 32-bit mode, an address is
base+index*scale+offset (with any part optional); any register is valid
for base and index.  In 16-bit mode, there is no scale, and only %bx and
%bp are valid for base, %si and %di for index.  As a result, in 16-bit
mode, %bx is usually call-clobbered whereas in 32-bit mode, %ebx is
call-saved.  It is also much harder to eliminate the frame pointer in
16-bit mode, since there is no %sp-based addressing at all.

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

[Rask Ingemann Lambertsen]

On Sat, Aug 18, 2007 at 10:46:23AM -0700, H. Peter Anvin wrote:

> We haven't, no.  In fact, adding in 386+ instructions was later
> modifications.  However, the application space we're targetting only
> focus on 386 level (not 286, not 486) and size optimization.
> 
> Daniel spent some serious time early on messing with the i386 backend --
> this was the original proposal -- but then decided that it was too
> complicated; we adopted modifying DJ's backend as a fallback position.
> Now, the *only* differences between 16-bit and 32-bit modes (on 32-bit
> capable chips) are the relative cost of HImode vs SImode (in 16-bit
> mode, HImode is by far cheaper in terms of code size) as well as the
> totally different structure of the 16-bit addressing modes[1].

   It is not different in your case! You're targetting the i386, so you can
use i386 addressing modes at just the cost of a 0x67 prefix:

$ echo -e '.code16\nleaw (%eax,%ecx,2),%bp' | as
$ objdump --wide --disassemble -m i8086 a.out

a.out:     file format elf32-i386

Disassembly of section .text:

00000000 <.text>:
   0:   67 8d 2c 48             addr32 lea (%eax,%ecx,2),%bp

   Obviously you want to save the 0x67 prefix whenever possible; use
"20(%bp)" instead of "20(%ebp)", for example.

   I target only i286 or less, so none of the fancy stuff is available.
Watch me being green with envy.

> It is also much harder to eliminate the frame pointer in
> 16-bit mode, since there is no %sp-based addressing at all.

   With disp(%esp) being valid on i386, you don't have that problem either.

   It's not so much the frame pointer elimination itself that's difficult on
the 16-bit chips, short of the odd reload bug or two, but doing so with an
advantage is difficult. Local-alloc and global-alloc don't know that the
frame pointer is being eliminated and therefore can't allocate a register to
it as needed. Reload knows the frame pointer is being eliminated, but is
only good for emergency fixups. There are corner cases where the code
quality suffers a lot.

-- 
Rask Ingemann Lambertsen

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

[H. Peter Anvin]

Rask Ingemann Lambertsen wrote:
> 
>    It is not different in your case! You're targetting the i386, so you can
> use i386 addressing modes at just the cost of a 0x67 prefix:
> 

Well, then you're effectively doing nothing other than the .code16gcc hack.

> $ echo -e '.code16\nleaw (%eax,%ecx,2),%bp' | as
> $ objdump --wide --disassemble -m i8086 a.out
> 
> a.out:     file format elf32-i386
> 
> Disassembly of section .text:
> 
> 00000000 <.text>:
>    0:   67 8d 2c 48             addr32 lea (%eax,%ecx,2),%bp
> 
>    Obviously you want to save the 0x67 prefix whenever possible; use
> "20(%bp)" instead of "20(%ebp)", for example.
> 
>    I target only i286 or less, so none of the fancy stuff is available.
> Watch me being green with envy.
> 
>> It is also much harder to eliminate the frame pointer in
>> 16-bit mode, since there is no %sp-based addressing at all.
> 
>    With disp(%esp) being valid on i386, you don't have that problem either.

If your environment isn't clean w.r.t. the top half of %esp, you can't
*ever* use this mode.  The stack pointer especially...

	-hpa

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

[Rask Ingemann Lambertsen]

On Sat, Aug 18, 2007 at 06:32:20PM -0700, H. Peter Anvin wrote:
> Rask Ingemann Lambertsen wrote:
> > 
> >    It is not different in your case! You're targetting the i386, so you can
> > use i386 addressing modes at just the cost of a 0x67 prefix:
> 
> Well, then you're effectively doing nothing other than the .code16gcc hack.

> >    Obviously you want to save the 0x67 prefix whenever possible; use
> > "20(%bp)" instead of "20(%ebp)", for example.

   I think that counts as "other than the .code16gcc hack". Using 16-bit
integers when possible does too. That's the opposite of what the i386 back
end does.

> >> It is also much harder to eliminate the frame pointer in
> >> 16-bit mode, since there is no %sp-based addressing at all.
> > 
> >    With disp(%esp) being valid on i386, you don't have that problem either.
> 
> If your environment isn't clean w.r.t. the top half of %esp, you can't
> *ever* use this mode.  The stack pointer especially...

   It doesn't seem to be a likely problem to me. Code operating on %sp can't
clobber the top half[1]. Code operating on %esp will need to restore it or run
into trouble. It would be very unusual to not restore the stack pointer. If
this was to be a problem, you wouldn't be able to just use ".code16gcc".

[1] Strictly speaking, only bits 16-19 are of any concern.

-- 
Rask Ingemann Lambertsen

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

[H. Peter Anvin]

Rask Ingemann Lambertsen wrote:
> 
>>>> It is also much harder to eliminate the frame pointer in
>>>> 16-bit mode, since there is no %sp-based addressing at all.
>>>    With disp(%esp) being valid on i386, you don't have that problem either.
>> If your environment isn't clean w.r.t. the top half of %esp, you can't
>> *ever* use this mode.  The stack pointer especially...
> 
>    It doesn't seem to be a likely problem to me. Code operating on %sp can't
> clobber the top half[1]. Code operating on %esp will need to restore it or run
> into trouble. It would be very unusual to not restore the stack pointer. If
> this was to be a problem, you wouldn't be able to just use ".code16gcc".
> 

It would be a bug, to be sure, and as I said, I haven't actually seen it
"in the wild" which is a good thing.  Given the kind of crap I've seen
BIOS vendors do, though, I can't rule it out.

> [1] Strictly speaking, only bits 16-19 are of any concern.

Uh, no.  Any bits [31:16] set will cause a segment violation.

	-hpa

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

[H. Peter Anvin]

Rask Ingemann Lambertsen wrote:
> On Sat, Aug 18, 2007 at 06:32:20PM -0700, H. Peter Anvin wrote:
>> Rask Ingemann Lambertsen wrote:
>>>    It is not different in your case! You're targetting the i386, so you can
>>> use i386 addressing modes at just the cost of a 0x67 prefix:
>> Well, then you're effectively doing nothing other than the .code16gcc hack.
> 
>>>    Obviously you want to save the 0x67 prefix whenever possible; use
>>> "20(%bp)" instead of "20(%ebp)", for example.
> 
>    I think that counts as "other than the .code16gcc hack". Using 16-bit
> integers when possible does too. That's the opposite of what the i386 back
> end does.

As an interesting mental exercise, I tried to see if I could get the
i386 backend to emit 16-bit code.  It now produces code for some very
simple functions, but I find myself getting stuck pretty hard on the
fact that the i386 backend seems to assume pretty hard that
word == Pmode == the width of a hard register, which is not true when
one wants to use 32-bit registers but have 16-bit addressing.

Another problematic issue is that I haven't, at least, figured out any
way by which one can tell that only part of a register has been
clobbered by a function.  This means spilling 32-bit registers to the
stack every time, with extra 66 bytes.  This, in fact, was the
motivation for using HImode registers in DrV's port (there seems to be
some issues with that which we haven't figured out, but that's probably
just naïveté on our part.)

Anyway, it was worth a few hours to look into whether or not generating
16-bit code for 32-bit chips could be done without being overly invasive
on the i386 backend.  Not sure if this is a productive direction based
on what I've seen so far.

	-hpa

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

[Rask Ingemann Lambertsen]

On Tue, Aug 21, 2007 at 01:45:35AM -0700, H. Peter Anvin wrote:
> 
> As an interesting mental exercise, I tried to see if I could get the
> i386 backend to emit 16-bit code.  It now produces code for some very
> simple functions, but I find myself getting stuck pretty hard on the
> fact that the i386 backend seems to assume pretty hard that
> word == Pmode == the width of a hard register, which is not true when
> one wants to use 32-bit registers but have 16-bit addressing.
> 
> Another problematic issue is that I haven't, at least, figured out any
> way by which one can tell that only part of a register has been
> clobbered by a function.  This means spilling 32-bit registers to the
> stack every time, with extra 66 bytes.

   Ah yes, there was that little detail. And if you split up the registers,
you would really have to audit the rest of the back end for assumptions that
register size == word size. That's probably not worth it for your project.

> This, in fact, was the
> motivation for using HImode registers in DrV's port (there seems to be
> some issues with that which we haven't figured out, but that's probably
> just naïveté on our part.)

   If it's simply saving too many registers, I think that's not quite unusual.
It sometimes happens with other back ends too.

-- 
Rask Ingemann Lambertsen

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

[H. Peter Anvin]

Rask Ingemann Lambertsen wrote:
> On Tue, Aug 21, 2007 at 01:45:35AM -0700, H. Peter Anvin wrote:
>> As an interesting mental exercise, I tried to see if I could get the
>> i386 backend to emit 16-bit code.  It now produces code for some very
>> simple functions, but I find myself getting stuck pretty hard on the
>> fact that the i386 backend seems to assume pretty hard that
>> word == Pmode == the width of a hard register, which is not true when
>> one wants to use 32-bit registers but have 16-bit addressing.
>>
>> Another problematic issue is that I haven't, at least, figured out any
>> way by which one can tell that only part of a register has been
>> clobbered by a function.  This means spilling 32-bit registers to the
>> stack every time, with extra 66 bytes.
> 
>    Ah yes, there was that little detail. And if you split up the registers,
> you would really have to audit the rest of the back end for assumptions that
> register size == word size. That's probably not worth it for your project.

More importantly, it violates the constraint of not destabilizing the
backend for non-16-bit code.  It probably also makes it slower, which is
another no-no.

At this point it is pretty clear that the 16-on-32 situation is pretty
different both from 16-on-16 and 32-on-32 as far as gcc is concerned.
Constructing a 16-on-32 backend from the ground up (with yours and DrV's
work as starting points) seems to be the probably the same amount of
work as modifying the i386 backend, but should result in a higher
confidence level, and doesn't have the risk of destabilize the singly
most intensively used backend in all of gcc.

>> This, in fact, was the
>> motivation for using HImode registers in DrV's port (there seems to be
>> some issues with that which we haven't figured out, but that's probably
>> just naïveté on our part.)
> 
>    If it's simply saving too many registers, I think that's not quite unusual.
> It sometimes happens with other back ends too.

It does that, but that's not the concern (that seems to be a result of
register renaming after pro- and epilogue generation.)

The issue, rather, is the following error, which I haven't figured out
the best way to address yet (mostly due to only running into it late
last week):

/home/hpa/kernel/test-gcc16/arch/i386/boot/video.c:461: internal
compiler error: in find_valid_class, at reload.c:699
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.

It happens mostly when compiling code which has previously been built
with .code16gcc, so I'm using -mint32.

It looks like it calls find_valid_class with (outer=HImode,
inner=SImode, n=1), however:

/* Find the largest class which has at least one register valid in
   mode INNER, and which for every such register, that register number
   plus N is also valid in OUTER (if in range) and is cheap to move
   into REGNO.  Such a class must exist.  */

This does, however, cause trouble since we only allow SImode and HImode
values in even registers; the odd registers being the upper half of a
register.  Other than that, we're down to generating valid code for a
fair number of the things I throw at it.

There seems to be two possible ways of dealing with it: either figuring
out why it's asking (and correct the cause), or allowing gcc to put a
HImode value into the high half of a register during reload.

Oh, and switching to a proper flags register is high on the list.

	-hpa

Real-mode i386 back end (Was: New back end ia16: 16-bit Intel x86)

[Rask Ingemann Lambertsen]

On Tue, Aug 21, 2007 at 10:44:46AM -0700, H. Peter Anvin wrote:
> The issue, rather, is the following error, which I haven't figured out
> the best way to address yet (mostly due to only running into it late
> last week):
> 
> /home/hpa/kernel/test-gcc16/arch/i386/boot/video.c:461: internal
> compiler error: in find_valid_class, at reload.c:699
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <URL:http://gcc.gnu.org/bugs.html> for instructions.
> 
> It happens mostly when compiling code which has previously been built
> with .code16gcc, so I'm using -mint32.
> 
> It looks like it calls find_valid_class with (outer=HImode,
> inner=SImode, n=1), however:
> 
> /* Find the largest class which has at least one register valid in
>    mode INNER, and which for every such register, that register number
>    plus N is also valid in OUTER (if in range) and is cheap to move
>    into REGNO.  Such a class must exist.  */
> 
> This does, however, cause trouble since we only allow SImode and HImode
> values in even registers; the odd registers being the upper half of a
> register.  Other than that, we're down to generating valid code for a
> fair number of the things I throw at it.

   This patch was once needed for my ia16 back end, but these days,
find_valid_class() isn't called any more. The problems with
find_valid_class() are still latent, though. The three problems I recall
being:

1) Assuming you can pass in a subreg_regno_offset and use it for any
register.
2) Not counting the number of registers in the class right.
3) Something about not checking HARD_REGNO_MODE_OK() enough.

   I'd like to know if the patch fixes your problem.

Index: reload.c
===================================================================
--- reload.c	(revision 126653)
+++ reload.c	(working copy)
@@ -252,7 +252,7 @@ static int push_secondary_reload (int, r
 				  enum machine_mode, enum reload_type,
 				  enum insn_code *, secondary_reload_info *);
 static enum reg_class find_valid_class (enum machine_mode, enum machine_mode,
-					int, unsigned int);
+					int, unsigned int, enum machine_mode);
 static int reload_inner_reg_of_subreg (rtx, enum machine_mode, int);
 static void push_replacement (rtx *, int, enum machine_mode);
 static void dup_replacements (rtx *, rtx *);
@@ -650,13 +650,15 @@ clear_secondary_mem (void)
 
 /* Find the largest class which has at least one register valid in
    mode INNER, and which for every such register, that register number
-   plus N is also valid in OUTER (if in range) and is cheap to move
-   into REGNO.  Such a class must exist.  */
+   plus subreg_regno_offset (regnum, INNER, OFFSET, OUTER2) is also valid
+   in OUTER (if in range) and is cheap to move into REGNO.
+   Such a class must exist.  */
 
 static enum reg_class
 find_valid_class (enum machine_mode outer ATTRIBUTE_UNUSED,
-		  enum machine_mode inner ATTRIBUTE_UNUSED, int n,
-		  unsigned int dest_regno ATTRIBUTE_UNUSED)
+		  enum machine_mode inner ATTRIBUTE_UNUSED, int offset,
+		  unsigned int dest_regno ATTRIBUTE_UNUSED,
+		  enum machine_mode outer2)
 {
   int best_cost = -1;
   int class;
@@ -666,16 +668,30 @@ find_valid_class (enum machine_mode oute
   unsigned int best_size = 0;
   int cost;
 
+  gcc_assert (outer2 == outer);
+
   for (class = 1; class < N_REG_CLASSES; class++)
     {
       int bad = 0;
       int good = 0;
-      for (regno = 0; regno < FIRST_PSEUDO_REGISTER - n && ! bad; regno++)
+      unsigned int nregs;
+      unsigned int class_size = 0;
+
+      for (regno = 0, nregs = hard_regno_nregs[0][inner];
+	   ((!HARD_REGNO_MODE_OK (regno, inner) && regno < FIRST_PSEUDO_REGISTER)
+	      || regno + nregs - 1 < FIRST_PSEUDO_REGISTER)
+	   && !bad;
+	   nregs = hard_regno_nregs[++regno][inner])
 	if (TEST_HARD_REG_BIT (reg_class_contents[class], regno))
 	  {
-	    if (HARD_REGNO_MODE_OK (regno, inner))
+	    /* We ought to check all registers [regno; regno + nregs - 1]. */
+	    /* nregs is bogus if ! HARD_REGNO_MODE_OK(). */
+	    if (HARD_REGNO_MODE_OK (regno, inner)
+	        && TEST_HARD_REG_BIT (reg_class_contents[class], regno + nregs - 1))
 	      {
+		int n = subreg_regno_offset (regno, inner, offset, outer);
 		good = 1;
+		class_size ++;
 		if (! TEST_HARD_REG_BIT (reg_class_contents[class], regno + n)
 		    || ! HARD_REGNO_MODE_OK (regno + n, outer))
 		  bad = 1;
@@ -686,18 +703,25 @@ find_valid_class (enum machine_mode oute
 	continue;
       cost = REGISTER_MOVE_COST (outer, class, dest_class);
 
-      if ((reg_class_size[class] > best_size
+      if ((class_size > best_size
 	   && (best_cost < 0 || best_cost >= cost))
 	  || best_cost > cost)
 	{
 	  best_class = class;
-	  best_size = reg_class_size[class];
+	  best_size = class_size;
 	  best_cost = REGISTER_MOVE_COST (outer, class, dest_class);
 	}
     }
 
   gcc_assert (best_size != 0);
 
+  {
+    FILE *log;
+    log = fopen ("/tmp/find_valid_class_log", "a");
+    fprintf (log, "(%s, %s, %d, %d) = %s\n", GET_MODE_NAME (outer),
+	     GET_MODE_NAME (inner), offset, dest_regno, reg_class_names[best_class]);
+    fclose (log);
+  }
   return best_class;
 }
 \f
@@ -1079,11 +1103,8 @@ push_reload (rtx in, rtx out, rtx *inloc
       if (REG_P (SUBREG_REG (in)))
 	in_class
 	  = find_valid_class (inmode, GET_MODE (SUBREG_REG (in)),
-			      subreg_regno_offset (REGNO (SUBREG_REG (in)),
-						   GET_MODE (SUBREG_REG (in)),
-						   SUBREG_BYTE (in),
-						   GET_MODE (in)),
-			      REGNO (SUBREG_REG (in)));
+			      SUBREG_BYTE (in), REGNO (SUBREG_REG (in)),
+			      GET_MODE (in));
 
       /* This relies on the fact that emit_reload_insns outputs the
 	 instructions for input reloads of type RELOAD_OTHER in the same
@@ -1173,11 +1194,8 @@ push_reload (rtx in, rtx out, rtx *inloc
       push_reload (SUBREG_REG (out), SUBREG_REG (out), &SUBREG_REG (out),
 		   &SUBREG_REG (out),
 		   find_valid_class (outmode, GET_MODE (SUBREG_REG (out)),
-				     subreg_regno_offset (REGNO (SUBREG_REG (out)),
-							  GET_MODE (SUBREG_REG (out)),
-							  SUBREG_BYTE (out),
-							  GET_MODE (out)),
-				     REGNO (SUBREG_REG (out))),
+				     SUBREG_BYTE (out),
+				     REGNO (SUBREG_REG (out)), GET_MODE (out)),
 		   VOIDmode, VOIDmode, 0, 0,
 		   opnum, RELOAD_OTHER);
     }

-- 
Rask Ingemann Lambertsen

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

[H. Peter Anvin]

Rask Ingemann Lambertsen wrote:
> 
>    I target only i286 or less, so none of the fancy stuff is available.
> Watch me being green with envy.
> 

I was thinking about usage spaces, there are pretty much the remaining
uses of 16-bit code as far as I can tell:

186+:	residual microcontroller use (80186/80188 were available for the
        microcontroller market until not all that long ago)
386+:	bootloaders, PCI card firmware
686+:	mainboard firmware, PCI-e card firmware

All of these are primarily constrained by space, so size optimization is
what really matters.  I have so far operated on the assumption that
16-bit addressing modes are more space-efficient than 32-bit ones,
despite the register allocation issues, due to the lack of 67 prefixes,
SIB bytes, 32-bit offsets and the occational need to save/restore a
32-bit register instead of a 16-bit one.

286, 486, and 586 don't really add enough instructions to be worth
worrying with, as far as I can see.  386 obviously adds 32-bit registers
and a whole bunch of useful instructions (movsx, movzx especially); 686
adds cmov (although that only saves one byte compared to a branch over a
mov.)

	-hpa

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

[Rask Ingemann Lambertsen]

On Sat, Aug 18, 2007 at 07:11:11PM -0700, H. Peter Anvin wrote:
> All of these are primarily constrained by space, so size optimization is
> what really matters.  I have so far operated on the assumption that
> 16-bit addressing modes are more space-efficient than 32-bit ones,
> despite the register allocation issues, due to the lack of 67 prefixes,
> SIB bytes, 32-bit offsets and the occational need to save/restore a
> 32-bit register instead of a 16-bit one.

   Mov reg,reg is two bytes, the 0x67 prefix is only one byte, so the 16-bit
modes are larger for disp(reg) any time the register allocater doesn't get
the register right. Fortunately, it doesn't happen too much since 4 out of 7
registers can be used. Except of course when accessing the stack, but here
the 32-bit form isn't any shorter, it just saves a register. disp(reg,reg)
addresses frequently don't get the right registers, but at long as one of
them is right, there is no space saved by the 32-bit form, but none wasted
either.

   0:   89 cb                   mov    %cx,%bx
   2:   8b 47 14                mov    20(%bx),%ax

   0:   67 8b 41 14             addr32 mov 0x14(%ecx),%ax

   0:   89 e3                   mov    %sp,%bx
   2:   8b 47 14                mov    20(%bx),%ax

   0:   67 8b 44 24 14          addr32 mov 0x14(%esp),%ax

   0:   89 cb                   mov    %cx,%bx
   2:   8b 41 14                mov    20(%bx,%di),%ax

   0:   67 8b 44 39 14          addr32 mov 0x14(%ecx,%edi,1),%ax

   Btw, you'll find that GCC will like to use lea to mupltiply by two. That
alone will result in many sequences like

	movw	%bx,	%di
	leaw	(%bx,%di),	%ax

which is a bit worse than

	movw	%bx,	%ax
	shlw	$1,	%ax

> 286, 486, and 586 don't really add enough instructions to be worth
> worrying with, as far as I can see.  386 obviously adds 32-bit registers
> and a whole bunch of useful instructions (movsx, movzx especially);

   mov[sz]x are very useful becase 3 out of 7 registers don't accept movb.
Additionally they are better for register allocation than the 8086
instructions.

   The i386 also added two more segment registers, making far pointers
approximately a no-brainer to implement in a compiler.

> 686 adds cmov (although that only saves one byte compared to a branch over
> a mov.)

   cmov was primarily thought of as a performance improvement.

-- 
Rask Ingemann Lambertsen

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

[H. Peter Anvin]

Rask Ingemann Lambertsen wrote:
> On Sat, Aug 18, 2007 at 07:11:11PM -0700, H. Peter Anvin wrote:
>> All of these are primarily constrained by space, so size optimization is
>> what really matters.  I have so far operated on the assumption that
>> 16-bit addressing modes are more space-efficient than 32-bit ones,
>> despite the register allocation issues, due to the lack of 67 prefixes,
>> SIB bytes, 32-bit offsets and the occational need to save/restore a
>> 32-bit register instead of a 16-bit one.
> 
>    Mov reg,reg is two bytes, the 0x67 prefix is only one byte, so the 16-bit
> modes are larger for disp(reg) any time the register allocater doesn't get
> the register right.

+2 bytes if the displacement is more than 8 bits, since you end up with
a 32-bit displacement instead of a 16-bit displacement.

>    Btw, you'll find that GCC will like to use lea to mupltiply by two. That
> alone will result in many sequences like
> 
> 	movw	%bx,	%di
> 	leaw	(%bx,%di),	%ax
> 
> which is a bit worse than
> 
> 	movw	%bx,	%ax
> 	shlw	$1,	%ax

I mostly see the second form, so far.  I presume having a proper cost
table should help.

>> 286, 486, and 586 don't really add enough instructions to be worth
>> worrying with, as far as I can see.  386 obviously adds 32-bit registers
>> and a whole bunch of useful instructions (movsx, movzx especially);
> 
>    mov[sz]x are very useful becase 3 out of 7 registers don't accept movb.
> Additionally they are better for register allocation than the 8086
> instructions.
>
>    The i386 also added two more segment registers, making far pointers
> approximately a no-brainer to implement in a compiler.
> 
>> 686 adds cmov (although that only saves one byte compared to a branch over
>> a mov.)
> 
>    cmov was primarily thought of as a performance improvement.
> 

Yup, hence us settling on 386 as the suitable CPU level.

	-hpa

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

[Ross Ridge]

Ross Ridge writes:
>You also need to add the cost zero extending the 16-bit pointer values to
>32-bits, so using 32-bit addressing modes will only rarely be worthwhile.

Rask Ingemann Lambertsen writes:
>Daniel and Peter have modelled the 32-bit registers with separate top
>and bottom halves to be able to keep track of when the top half has
>been touched.

I was assuming optimizations like this.  Even with hand optimized 16-bit
assembly it's hard to use the 32-bit addressing modes effectively. 

>> Code that operates on SP only needs to set or restore SP to work
>> correctly.
>
>It also doesn't clobber the upper half of %esp, obviously it doesn't need
>to restore it.

Code that clobbers the upper half of ESP doesn't need to restore it for
code the only uses SP to work correctly.  From GCC's perspective, this is
a calling convention issue.  In the 16-bit IA-32 calling convetions the
upper 16-bits of all the 32-bit registers (other than EIP) are undefined
at entry and are all call clobbered.  It might be worth while for H. Peter
Anvin and Daniel Verkamp's port to have an option where GCC assumes the
higher 16-bits of ESP are zero, but the "ABI" doesn't guarantee this.

>> No.  The full 32-bit segment offset is checked against the segment limit
>> in both real mode and 16-bit protected mode.  Even if that weren't the
>> case, and it's possible to trick the CPU to use a segment limit other
>> than 0xFFFF in real mode, all 32-bits of ESP would be used to calculate
>> the 32-bit linear address.
>
>I'm just going by the documented maximum real address mode address of
>0xfffff.

The actual documented maximum real mode address is 0x10FFEF.  In 16-bit
protected mode the segment limits can be set arbitrarily.

>  It's OK if the CPU raises an exception; my worry would have been
>silent stack corruption.

That's absurd.  It's not OK for GCC to generate code that would cause
a correct program to crash.

					Ross Ridge

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

[Ross Ridge]

Rask Ingemann Lambertsen writes:
>It doesn't seem to be a likely problem to me. Code operating on %sp
>can't clobber the top half[1]. Code operating on %esp will need to
>restore it or run into trouble. It would be very unusual to not restore
>the stack pointer.

Code that operates on SP only needs to set or restore SP to work
correctly.

>If this was to be a problem, you wouldn't be able to just use
>".code16gcc".

Yes.

>[1] Strictly speaking, only bits 16-19 are of any concern.

No.  The full 32-bit segment offset is checked against the segment limit
in both real mode and 16-bit protected mode.  Even if that weren't the
case, and it's possible to trick the CPU to use a segment limit other
than 0xFFFF in real mode, all 32-bits of ESP would be used to calculate
the 32-bit linear address.

					Ross Ridge

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

[Rask Ingemann Lambertsen]

On Sun, Aug 19, 2007 at 11:13:06AM -0400, Ross Ridge wrote:
> Rask Ingemann Lambertsen writes:
> >It doesn't seem to be a likely problem to me. Code operating on %sp
> >can't clobber the top half[1]. Code operating on %esp will need to
> >restore it or run into trouble. It would be very unusual to not restore
> >the stack pointer.
> 
> Code that operates on SP only needs to set or restore SP to work
> correctly.

   It also doesn't clobber the upper half of %esp, obviously it doesn't need
to restore it.

> >If this was to be a problem, you wouldn't be able to just use
> >".code16gcc".
> 
> Yes.
> 
> >[1] Strictly speaking, only bits 16-19 are of any concern.
> 
> No.  The full 32-bit segment offset is checked against the segment limit
> in both real mode and 16-bit protected mode.  Even if that weren't the
> case, and it's possible to trick the CPU to use a segment limit other
> than 0xFFFF in real mode, all 32-bits of ESP would be used to calculate
> the 32-bit linear address.

   I'm just going by the documented maximum real address mode address of
0xfffff. It's OK if the CPU raises an exception; my worry would have been
silent stack corruption.

-- 
Rask Ingemann Lambertsen

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

[Ross Ridge]

Rask Ingemann Lambertsen writes:
>It is not different in your case! You're targetting the i386, so you
>can use i386 addressing modes at just the cost of a 0x67 prefix

You also need to add the cost zero extending the 16-bit pointer values to
32-bits, so using 32-bit addressing modes will only rarely be worthwhile.
Unlike with 16-bit integers, which are available in both 16-bit and
32-bit modes, 16-bit pointers are where in practice real space savings
can be acheived.

>With disp(%esp) being valid on i386, you don't have that problem either.

Only if you can assume the higher 16-bits of ESP are zero.

					Ross Ridge

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

[Rask Ingemann Lambertsen]

On Sat, Aug 18, 2007 at 04:39:32PM -0400, Ross Ridge wrote:
> Rask Ingemann Lambertsen writes:
> >It is not different in your case! You're targetting the i386, so you
> >can use i386 addressing modes at just the cost of a 0x67 prefix
> 
> You also need to add the cost zero extending the 16-bit pointer values to
> 32-bits, so using 32-bit addressing modes will only rarely be worthwhile.

   Daniel and Peter have modelled the 32-bit registers with separate top and
bottom halves to be able to keep track of when the top half has been
touched. With that in place, they can set the top half to zero every time
they need it that way and if the top half was unmodified from the last time
they did so, the instruction to clear the top half should be optimized away
automatically. The advantage of being able to use %ax, %cx and %dx as
base registers only begins to show up with more than 3 pointer variables
live at the same time. I don't know if that happens frequently or not.

   The see pass should also be able to optimize away zero extensions, but I
hear it has bitrotted to the point of not being usable. It also works only
on pseudo registers.

-- 
Rask Ingemann Lambertsen

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

[Ross Ridge]

Rask Ingemann Lambertsen writes:
> Used for what exactly?

Never mind.  You've convinced me that you don't see your port as anything
more than a toy.

					Ross Ridge

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

[Ross Ridge]

Ross Ridge wrote:
> I have 16-bit C code, that when compiled with my 16 year-old Borland
> C++ compiler, produces code that uses 32-bit registers and instructions.

Rask Ingemann Lambertsen writes:
>   Why cant the latter group do what the Linux kernel does? That is, use
>i386 gcc and i386 binutils for low-level 16-bit system code targetting an
>i386 or better.

I can't speak for anyone but myself, but I don't use hacks like
".code16gcc" or code everything assembly because I've got a fully
functional 16-bit IA-32 C compiler that I can use instead.  It would be
nice to use GCC entirely in my projects but I'm not going to replace a
working tool with a broken one to do so.

Let me ask you question.  Are you serious about this port?  Is it just a
toy, a fun project to work on, or do you expect to be used for serious
development?  Who do you expect to use the port?  If you're serious
about this port then you shouldn't be asking why people can't the same
hacks the Linux kernel does, but instead if your port couldn't be used
one day with Linux kernel.

On the other hand, if it's ment to be little more than a toy then you
can just ignore everything I've said.  The name "ia16" is still wrong,
but if it's just going to become, at best, a little-used embedded target,
I really don't care what you call it.

					Ross Ridge

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

[Rask Ingemann Lambertsen]

On Wed, Aug 01, 2007 at 03:25:17PM -0400, Ross Ridge wrote:
[...]
> but instead if your port couldn't be used
> one day with Linux kernel.

   Used for what exactly?

-- 
Rask Ingemann Lambertsen

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

[Andi Kleen]

rridge@csclub.uwaterloo.ca (Ross Ridge) writes:

> Thoses writing embedded applications targeting the 80186
> and those writing low-level 16-bit system code, like boot loaders.
> The later group of people are targetting at least i386 processors, and

Those seem to be already served well enough by ".code16gcc" and the i386
backend. But that hack cannot support real 16bit CPUs.

-Andi

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

[Ross Ridge]

Rask Ingemann Lambertsen writes:
>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.

Except for the first point, your port should take advantage of the
improvements made in those areas.

As I see it, there's two groups of developers who would want to use
your port.  Thoses writing embedded applications targeting the 80186
and those writing low-level 16-bit system code, like boot loaders.
The later group of people are targetting at least i386 processors, and
can often assume more modern processors are being used.  I have 16-bit
C code, that when compiled with my 16 year-old Borland C++ compiler,
produces code that uses 32-bit registers and instructions.  I think
features like this would be a lot more useful today in a 16-bit IA-32
compiler than getting the RTX costs right on a processor like the 80286
that hasn't been made in a couple of decades.

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

Like I said, while ideally they should be merged, I can see good reasons
for not doing so.  I'm not really arguing for that, at least not at
this point.

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

Ideally, the 16-bit port should support the entire IA-32 instruction set,
and I don't see that happening if the ports aren't merged.  Maybe it
will be never worth the trouble, but it would make your port a lot more
useful to me.

					Ross Ridge

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

[Rask Ingemann Lambertsen]

On Wed, Aug 01, 2007 at 11:37:58AM -0400, Ross Ridge wrote:
> As I see it, there's two groups of developers who would want to use
> your port.  Thoses writing embedded applications targeting the 80186
> and those writing low-level 16-bit system code, like boot loaders.
> The later group of people are targetting at least i386 processors, and
> can often assume more modern processors are being used.  I have 16-bit
> C code, that when compiled with my 16 year-old Borland C++ compiler,
> produces code that uses 32-bit registers and instructions.

   Why cant the latter group do what the Linux kernel does? That is, use
i386 gcc and i386 binutils for low-level 16-bit system code targetting an
i386 or better.

-- 
Rask Ingemann Lambertsen

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

[Ross Ridge]

Michael Matz writes:
> Blaeh, that's all ugly.  I actually think that ia16 is a reasonable name 
>for this ISA, even though Rask just made it up.

I think "ia16" is an ugly backformation and being made up like this
there's a risk of it conflicting with something else in the future.

>It's generating code for the 16 bit mode (which works on all the intel
>CPUs) which for all practical measures is a different CPU architecture
>than the same chip in 32bit or 64bit mode (it just happens to share some
>mnemonics and insn encodings).

That's absurd.  By sharing the same instruction set and registers, for
"all practical measures" it is the same CPU architecture.  There's a
bigger difference between 32-bit and 64-bit mode and GCC doesn't treat the
x86_64 as a different architecture.  Ideally a 16-bit IA-32 port should
be merged into the i386 port, just like the x86_64 port.  Given the
limitations of Rask Ingemann Lambertsen's port I'm not entirely sure
why it wasn't, though I can see some good reasons for keeping it seperate.

					Ross Ridge

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

[Rask Ingemann Lambertsen]

On Tue, Jul 31, 2007 at 01:44:56PM -0400, Ross Ridge wrote:
> Michael Matz writes:
> > Blaeh, that's all ugly.  I actually think that ia16 is a reasonable name 
> >for this ISA, even though Rask just made it up.
> 
> I think "ia16" is an ugly backformation and being made up like this
> there's a risk of it conflicting with something else in the future.

   I did not make it up. Try asking Google for "Intel IA16" or "Intel
IA-16". At least one search result is 7 (seven) years old. It is also clear
from the search results that outside of Intel, IA16 or IA-16 means the
16-bit x86 family members i8086-i80286 and IA32 or IA-32 means x86 family
members starting with the i80386.

> >It's generating code for the 16 bit mode (which works on all the intel
> >CPUs) which for all practical measures is a different CPU architecture
> >than the same chip in 32bit or 64bit mode (it just happens to share some
> >mnemonics and insn encodings).
> 
> That's absurd.  By sharing the same instruction set and registers, for
> "all practical measures" it is the same CPU architecture.

   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.

   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

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

[Richard Kenner]

> I did not make it up. Try asking Google for "Intel IA16" or "Intel
> IA-16". At least one search result is 7 (seven) years old. It is also clear
> from the search results that outside of Intel, IA16 or IA-16 means the
> 16-bit x86 family members i8086-i80286 and IA32 or IA-32 means x86 family
> members starting with the i80386.

I just did that search and I must say that I'm not that convinced.  The few
references that I find are like this Anonymous post that says "It just
might be 15 years before ia64 bit software is in wide use, much like the
transition between ia16 and ia32 of the past.." 

I'm seeing perhaps a dozen original uses of ia16, but I'm not sure that's
enough to classify it as an accepted usage.

Although even such usage might be enough to prevent somebody from naming
an "ia16" architecture, it also might not, so that's a risk.

But my main problem with it is that it's not a different architecture.
IA32 and IA64 are different.  But what you're calling "ia16" is really what
we'd call "x86_16" analogously to "x86_64".  I think this really should be
a modification to the i386 port, as others have suggested.

If it has to be a separate port, my vote would be "x86_16".

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

[Rask Ingemann Lambertsen]

On Wed, Aug 01, 2007 at 05:56:57AM -0400, Richard Kenner wrote:

> I think this really should be
> a modification to the i386 port, as others have suggested.

   Could you give an outline of the benefits of merging it with the i386
port?

-- 
Rask Ingemann Lambertsen

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

[Richard Kenner]

> Could you give an outline of the benefits of merging it with the i386 port?

It's a subset of the registers and basically the same instruction set.
It has exactly the same relationship to the i386 port as the i386 port
has to the x86_64 port and that's merged.

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

[Rask Ingemann Lambertsen]

On Wed, Aug 01, 2007 at 08:47:25AM -0400, Richard Kenner wrote:
> > Could you give an outline of the benefits of merging it with the i386 port?
> 
> It's a subset of the registers and basically the same instruction set.
> It has exactly the same relationship to the i386 port as the i386 port
> has to the x86_64 port and that's merged.

   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.

-- 
Rask Ingemann Lambertsen

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

[Richard Kenner]

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

It's primarily a maintenance issue, but, of course, if something is easier
to maintain it usually ends up better on other metrics down the road.

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

[Jan Hubicka]

>    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

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

[Rask Ingemann Lambertsen]

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

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

[Ross Ridge]

Rask Ingemann Lambertsen writes:
> It is the best I can think of. Probably my preference was for x86-16,
>but that's not possible (see below). With IA-32 and IA-64 being well
>established, I think IA-16 is a good choice because it conveys the
>information that it's Intel's 16-bit architecture.

It's not Intel's 16-bit architecture, that's the problem.  It's Intel's
IA-32 architecture in 16-bit mode.  Your port seems to be limited to
just the 16-bit IA-32 CPUs, but architecturely there's no reason why
the port couldn't use, for example, SSE instructions and registers.
They work in both real mode and 16-bit protected mode.

>>According to Intel, processors like the 8086 and 80286 are part of the IA-32
>> architecture and there is no IA-16.
>
> Interesting idea. There was no IA-32 until the 80386 appeared.

There was no IA-32 until the Itanium and the IA-64 architecture appeared.
The architecture didn't have a consistant formal name until then.

> The "32" in "IA-32" of course refers to the fact that it is a
>32-bit architecture, unlike the previous members of the x86 family.

No, the "32" is there to distingish it from the IA-64 architecture.
When Intel introduced the IA-32 name, processors like the 8086 and 808186
were explictly documented as being part of the architecture.  Like other
CPU architectures it encompasses 16-bit, 32-bit and now 64-bit processors.

>The "i386" name was a mistake and should not be repeated...

Given the lack of a formal name at the time it seems a reasonable enough
choice to me.

> (so "i8086" is out as well).

Well, if your port is going to be strictly limitted to targetting only
16-bit IA-32 processors then "i80x86" would probably be most descriptive
and accurate name for the target.  However, I don't see why it should
be limitted to just 16-bit processors.

>I'm sure that dashes in the back end name will be rejected.
>Consider the s/x86-64/x86_64/h mess.

I did say "something like i386-16" so "i386_16", "ia32rm16" or anything
that indicates that IA-32 processors in 16-bit mode are being targetted.

					Ross Ridge

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

[Michael Matz]

Hi,

On Tue, 31 Jul 2007, Ross Ridge wrote:

> > (so "i8086" is out as well).
> 
> Well, if your port is going to be strictly limitted to targetting only 
> 16-bit IA-32 processors then "i80x86" would probably be most descriptive 
> and accurate name for the target.  However, I don't see why it should be 
> limitted to just 16-bit processors.
> 
> >I'm sure that dashes in the back end name will be rejected. Consider 
> >the s/x86-64/x86_64/h mess.
> 
> I did say "something like i386-16" so "i386_16", "ia32rm16" or anything 
> that indicates that IA-32 processors in 16-bit mode are being targetted.

Blaeh, that's all ugly.  I actually think that ia16 is a reasonable name 
for this ISA, even though Rask just made it up.  It's generating code for 
the 16 bit mode (which works on all the intel CPUs) which for all 
practical measures is a different CPU architecture than the same chip in 
32bit or 64bit mode (it just happens to share some mnemonics and insn 
encodings).  At least to me the name ia16 (which never occured to me 
before Rask) immediately made clear what this backend is about.  True, 
i8086 would too, but that wouldn't be completely correct as the i80286 can 
also work in that architecture mode.  ia32rm16 could be understood too, 
true, but given the non-existence of the term ia-32 before IA-64 came up 
would be at least as dubious as ia16 but longer and uglier.

Basically Rask needs a name for that ISA.  A chip name is not really 
appropriate (that has to be left for tuning purposes).  IA-32 also isn't 
appropriate (even if Intel documents the < 386 CPUs to also be included in 
that name, as name for the ISA this doesn't make sense, only as 
differentiator to IA-64).  The most logical choice for that old ISA seems 
to be IA-16 IMO.


Ciao,
Michael.

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

[Ross Ridge]

Rask Ingemann Lambertsen writes:
> This is a patch set to add a new back end for 16-bit x86 CPUs. 

Umm... is "ia16" the best name for this target?  According to Intel,
processors like the 8086 and 80286 are part of the IA-32 architecture and
there is no IA-16.  I think a more accurate name would be something like
"i386-16" since the new target is really just a 16-bit variation of what
GCC calls the i386 architecture.

					Ross Ridge

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

[Tristan Gingold]

On Jul 31, 2007, at 2:01 AM, Ross Ridge wrote:

> Rask Ingemann Lambertsen writes:
>> This is a patch set to add a new back end for 16-bit x86 CPUs.
>
> Umm... is "ia16" the best name for this target?  According to Intel,

I also find ia16 cryptic, unless this is a standard name I am not  
aware of.
i8086 is IMHO better than i386-16 (and dashes shouldn't appear in cpu  
names).

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

[Rask Ingemann Lambertsen]

On Mon, Jul 30, 2007 at 08:01:01PM -0400, Ross Ridge wrote:
> Rask Ingemann Lambertsen writes:
> > This is a patch set to add a new back end for 16-bit x86 CPUs. 
> 
> Umm... is "ia16" the best name for this target?

   It is the best I can think of. Probably my preference was for x86-16, but
that's not possible (see below). With IA-32 and IA-64 being well
established, I think IA-16 is a good choice because it conveys the
information that it's Intel's 16-bit architecture.

> According to Intel, processors like the 8086 and 80286 are part of the IA-32
> architecture and there is no IA-16.

   Interesting idea. There was no IA-32 until the 80386 appeared.
Unsurpricingly, there is also no mention of IA-32 in the Intel 80186
documentation. The "32" in "IA-32" of course refers to the fact that it is a
32-bit architecture, unlike the previous members of the x86 family.

> I think a more accurate name would be something like
> "i386-16" since the new target is really just a 16-bit variation of what
> GCC calls the i386 architecture.

   The "i386" name was a mistake and should not be repeated (so "i8086" is
out as well). I'm sure that dashes in the back end name will be rejected.
Consider the s/x86-64/x86_64/h mess.

-- 
Rask Ingemann Lambertsen