To read all comments associated with this story, please click here.
This arguments is a bit obsolete now, as most of the die is cache anyway.
I once read an analysis by a chip hardware guy, why the x86 architecture refuses to die.
His argument was like this: RISC-like architectures need no die space for that translation layer, but more instructions have to be stored in cache.
Imagine calculating a sinus: One instruction in x86, a whole algorithm in RISC. The translation layer of the x86 makes the one instruction to become the same algorithm as on RISK internally, but for caching and bus transfer purposes only one 32 bit command has to be considered, whereas for RISK it most often will be a much larger amount.
That leads to "more of the program can be stored in cache" for x86, and subsequently to faster execution. Loosing some speed in the translation layer is the disadvantage this architecture has, but as with all things tech: The best compromise is "The Solution", no matter how outstanding one of the pieces may be.
I believe it depends on the software.
You don't copy the sinus routine x times. You do it once and you call it with some kind of jump command. It should still take less space than the translation layer because your software will never use all routines.
Moreover, you can make better routines in software when you know what they are used for. You just need clever compilers.
His argument was like this: RISC-like architectures need no die space for that translation layer, but more instructions have to be stored in cache.
This is only true if you compare the best CISC with the worst RISC (in terms of code density), say Motorola 86K against MIPS. Modern x86 code is not really very compact. ARM with the Thumb2 ISA has, generally, much better code density than x86. Sure, you can find examples of a single x86 instruction that needs a sequence of ARM instructions, but the converse is also true, but that is really besides the point: You need to look at the average code density over a large set of programs.
Wrong anology. FPU transcendent instructions are very slow. And it isn't supported in 64 bit Windows anyway. You need to code the sinus in RISC way to be fast. And the code footprint here can be worse for x86 because of long SSE instructions encoding and lack of MAD instruction.
Maybe, but during that sinus calculation by x86 - the RISC will fill and empty its cache several times... there's wrong assumption, that x86 and RISC are of the same speed; no, RISC is much faster.





Member since:
2006-01-06
Intel's greatest strength is their manufacturing. They sure can make the hell transistors and small ones at that. With x86 as a dominaning platform they've got a good base and they can manufacture it.
Intel's greatest weakness is x86. "x86" processors don't actually run x86 instructions, they translate them into a different instruction set that the cpu actually runs. This extra space requires a crapload of transistors and die space. That means an x86 core compared with an arm core has to have way more transistors to do the same amount of work the arm core does.
So to compete outside their market (the embedded space), their manufacturing technology has to kick ass over their competitor's manufacturing to the extent that they are able to both overcome the issue with extra transistors and even beat their competition to overcome current inertia.
So the question is: how far behind are all the other non x86 manufacturers compared with intel ?