Re: Fazing out x86

Torben Ægidius Mogensen wrote:
nospam@xxxxxxxxxxxxxxxx (Niels Jørgen Kruse) writes:

Benny Amorsen <benny+usenet@xxxxxxxxxx> wrote:

x86 code is dense. That's a large advantage for general-purpose code.
Are there any RISCs that are as dense, apart from ARM with Thumb?
The difference is not all that. I checked the sizes of a few universal
binaries:
ppc i386 % ppc/i386
EyeTV 16239092 15764404 3.01
iTunes 14873344 14577664 2.03
MacSOUP 936764 838868 11.7
Camino 13597232 13674444 -0.565
Cyberduck 58320 59608 -2.16

It used to be the case that RISC code was larger than CISC, but that
is mostly no longer true. This is in part because RISC processors
have added features that make the code smaller and partly because the
compilers are becoming more similar. Also, I wouldn't call x86 code
compact -- that might have been true for pure 16-bit code, but the
32-bit additions added prefix bytes to instructions which lowered the
density. Also, with fewer registers, more things need to be stored in
memory, which required more instructions.

One embarassingly bad case is loading an arbitrary 64-bit constant into a register on x86-64 vs SPARC. On x86-64 its a 10-byte instruction, a 2-byte opcode followed by an 8-byte constant. On SPARC its 24 bytes, a pair of sethi/orlo for the two 32-bit halves followed by a shift and an add to combine the halves.

JIT VMs do this kind of thing, embedding pointers in code that may need to be updated by the garbage collector or the in-line cache machinery. The code generator can't analyse the value to generate a shorter load sequence since later the GC may need to update the value or the in-line cache manager may need to replace the value.

Even before Thumb, ARM had code density competitive with x86, and with
later additions (not just Thumb, but also 16-bit memory transfers and
other special-case instructions) became moreso.

Again ARM doesn't do well loading arbitrary constants. Its got lots of tricks for compact loading of specific constants, but loading an arbitrary 32-bit constant takes 16 bytes.

And yes this may lead one to rewrite the code generator to allow loading constants from a constant table.

--
The surest sign that intelligent life exists elsewhere in Calvin &
the universe is that none of it has tried to contact us. Hobbes.
--
Eliot ,,,^..^,,, Smalltalk - scene not herd
.

Relevant Pages

  • Re: Difference Between ARM and THUMB
    ... >>The above link tells you the advantages of Thumb over ARM, ... since it has 32-bits to encode in. ... >>Thumb instructions (available on almost all ARM ...
    (comp.sys.arm)
  • Re: Difference Between ARM and THUMB
    ... >>>The above link tells you the advantages of Thumb over ARM, ... >>>Thumb instructions (available on almost all ARM ... operand right after the 32-bit instruction? ...
    (comp.sys.arm)
  • Re: Luminary Micro cut the price of their dev boards from $775 to $249.
    ... Some instructions in Thumb-2 are 32 bit instructions!!!! ... 32 bit thumb instructions if same thing can be achieved by ARM ...
    (comp.sys.arm)
  • Re: Difference Between ARM and THUMB
    ... The above link tells you the advantages of Thumb over ARM, ... - no condition codes on most Thumb instructions (available on almost all ARM ... John Penton, posting as an individual unless specifically indicated ...
    (comp.sys.arm)
  • Re: Hi
    ... For history of older ARM architectures, the Wikipedia got a nice table ... ARM7 is based on arch v4, with ARM instructions only. ... ARM1136 come with a new architecture, which include new instructions, ... But Cortex-M3 doesn't not support ARM ...
    (comp.sys.arm)