Linus Has Harsh Words For Itanium

Anonymous Coward writes "As a follow up to the earlier story "Intel: No Rush to 64-bit Desktop"... In words that Intel are likely to be far from happy with, the Finnish luminary has stuck the boot into Itanium. His responses to some questions on processor architecture are sure to be music to AMD's ears. Linus, in an Inquirer interview concludes: "Code size matters. Price matters. Real world matters. And ia-64... falls flat on its face on ALL of these."" Of course, Linus works for a chip maker ;)

Comments

Re:Code size?

[hpa]

Code size matters because *cache* isn't cheap. Worse, you can't make L1 cache arbitrarily fast without slowing down your chip big time.

Re:Linus holding on to his security blanket?

[squiggleslash]

I just don't get RISC chips. Why they want to remove things that make programming easier is beyond me.

It's not stuff that "makes programming easier" that gets removed in RISC, its the more complex try-to-do-everything instructions which are a pain to implement in silicon and which ultimately can just as easily be done via a sequence of simpler instructions that may well, for a programmer who's actually programming at that level, be easier to understand.

Early on the chief advantage of the approach was that you could use the freed silicon for things like extra registers, and that's exactly the approach taken by Acorn (now ARM) and the PowerPC range. Would you prefer to have eight registers and a single byte copy-block instruction, or 64 registers and have to replace that copy-block instruction with (*gasp*) three simpler instructions?

(Actually, I guess that depends on how good your cache is. There's no such thing as a free lunch)

Re:Inquirer does not do the post justice

[cbiffle]

Probably (IANLT) he's referring to the various prefix encodings and variations for instructions. From my x86 manual, "Machine language instructions...vary in length from 1 to as many as 13 bytes. ...There are over 20,000 variations."

Now, granted, that rather large number probably includes different target registers, but compared to (to use your example) the 68k, the x86's encoding format is just -weird-:
16-Bit:
-An opcode. Either 1 or 2 bytes.
-Some flags and/or target register. 1 byte, optional
-Displacement. 0-2 bytes.
-Immediate. 0-2 bytes.

32-Bit:
-Optional address size prefix byte.
-Optional operand size prefix byte.
-Like above, but with 0-4-byte displacement/immediate and optional scaled index byte.

Now consider the fact that many opcodes implicitly reference registers. Decoding this instruction set by hand would be a royal bitch, and it's exactly the sort of configuration that RISC targeted for demise.
However, Linus makes a good point in the e-mail, which is (paraphrased) that the x86 encoding is basically a very good compression algorithm for its code. While the RISC machines that use 32 or 64-bits for every instruction may be more regular, their code does tend to be larger.

The ironic thing, in my mind, is that the IA-64's encoding is in many ways -more- baroque than the x86s! Instructions in bundles, bundles in groups (or is it the other way around? I never remember), flags at the end to specify how to interpret the instructions before -- it's an interesting take on VLIW, in that it doesn't specify the number of execution units, but YUCK. :-)