Comment Re: isn't x86 RISC by now? (Score 2) 161
You make a lot of good points. But any time you create a processor with cache miss prediction as well as branch prediction as well as execution parallelization, the instruction set has almost no effect at all.
You're suggesting that the instruction set interpretation is a separate unit to to out of order execution code. In reality, the first stage of any highly optimized modern CPU able to minimize pipeline misses must actually "recompile the code" (an oversimplification) in hardware before the actual execution unit and any intelligent designer would simplify the operations into much wider RISC style operations in the pipeline(s).
A purely in-order processor would certainly suffer from using a variable length instruction set.
What many people fail to realize is that ARM is very much a CISC ISA as well, but with a wider fixed sized word. So instead of increment ing instruction lengths by single byte units, ARM has two byte wide units in Thumb mode and four byte wife increments in ARM mode. Either way, it's nothing like MIPS (which is a dinosaur) which is a pure RISC architecture.
With the exception of a rare set of ULIW DSP cores (TI), it doesn't really matter. The major performance booster DSPs have is that code for a DSP are generally very small programs with extremely long pre-optimized pipelines which are not intended to be run in a task switching environment. Those processors don't need translation because they're completely pre-optimized. They also don't tend to have memory fragmentation and almost never have MMUs.
General purpose CPUs run code all ass-backwards because the code is unpredictable. The ISA will almost always benefit most from having as many possible version of instructions as possible for performance per watt.
The trick will be how to detect when specific units aren't needed and power them down when possible. Compilers and ISA will have no impact on this... Unless instructions are added to power on and off units explicitly based on the code entering the pipeline.
You're suggesting that the instruction set interpretation is a separate unit to to out of order execution code. In reality, the first stage of any highly optimized modern CPU able to minimize pipeline misses must actually "recompile the code" (an oversimplification) in hardware before the actual execution unit and any intelligent designer would simplify the operations into much wider RISC style operations in the pipeline(s).
A purely in-order processor would certainly suffer from using a variable length instruction set.
What many people fail to realize is that ARM is very much a CISC ISA as well, but with a wider fixed sized word. So instead of increment ing instruction lengths by single byte units, ARM has two byte wide units in Thumb mode and four byte wife increments in ARM mode. Either way, it's nothing like MIPS (which is a dinosaur) which is a pure RISC architecture.
With the exception of a rare set of ULIW DSP cores (TI), it doesn't really matter. The major performance booster DSPs have is that code for a DSP are generally very small programs with extremely long pre-optimized pipelines which are not intended to be run in a task switching environment. Those processors don't need translation because they're completely pre-optimized. They also don't tend to have memory fragmentation and almost never have MMUs.
General purpose CPUs run code all ass-backwards because the code is unpredictable. The ISA will almost always benefit most from having as many possible version of instructions as possible for performance per watt.
The trick will be how to detect when specific units aren't needed and power them down when possible. Compilers and ISA will have no impact on this... Unless instructions are added to power on and off units explicitly based on the code entering the pipeline.