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

[rridge@csclub.uwaterloo.ca (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