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

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

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