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

["H. Peter Anvin" <hpa@zytor.com>]

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