4 ms·

Back in the 80s, instruction decode was a large part of the logic in a CPU (thus the motivation for RISC). Currently, it's a tiny fraction. It's been many years

by Zaak 9y ago

Back in the 80s, instruction decode was a large part of the logic in a CPU (thus the motivation for RISC). Currently, it's a tiny fraction. It's been many years since a simpler instruction set was useful for reducing the complexity of the CPU.

wtallis 9y ago
But that portion of the power budget hasn't shifted at all back toward the computational units. It's been taken over by register renaming and instruction reordering and all manner of caches.
- adrianratnapala 9y ago
  But is RISC the solution to that problem? Having lots of registers helps, I guess. But the amd64 already has quite a lot. These problems seem to be what VLIW architectures like tried to to solve. Is that sort of architecture going to make a comeback? Will even that help?
  - rbanffy 9y ago
    > But the amd64 already has quite a lot. 16 registers is not a lot when compared to other architectures. POWER, SPARC, Arm64 and MIPS have 32 (SPARC is weird, but 32 are always visible). Itanium has 128.
    - luca_ing 9y ago
      I'm far from an expert on CPU architectures, but I suppose there are diminishing returns. Most of my functions use less than 16 values, and those that do may well iterate over more than 128. Also you're probably aware that modern CPUs have many more physical registers, they just don't expose them all at the same time. E.g. AMD Zen physically has 168 integer and 160 floating-point registers. Of which you can only use 16 at a time, but to my uninformed eye that looks like a reasonable trade-off.
- Zaak 9y ago
  If you had a "sufficiently smart compiler" you wouldn't need register renaming and instruction reordering, but such a compiler has consistently failed to appear. That's a big part of the whole Itanium fiasco. If you want your CPU to run fast, you have to pipeline instructions and you need caches that can run at full CPU speed. It's easy to design a CPU without all the complexity, but it will be slow. No one knows how to do both simple and fast. It's probably impossible.

by Zaak 9y ago

wtallis 9y ago

But that portion of the power budget hasn't shifted at all back toward the computational units. It's been taken over by register renaming and instruction reordering and all manner of caches.

adrianratnapala 9y ago
But is RISC the solution to that problem? Having lots of registers helps, I guess. But the amd64 already has quite a lot. These problems seem to be what VLIW architectures like tried to to solve. Is that sort of architecture going to make a comeback? Will even that help?
- rbanffy 9y ago
  > But the amd64 already has quite a lot. 16 registers is not a lot when compared to other architectures. POWER, SPARC, Arm64 and MIPS have 32 (SPARC is weird, but 32 are always visible). Itanium has 128.
  - luca_ing 9y ago
    I'm far from an expert on CPU architectures, but I suppose there are diminishing returns. Most of my functions use less than 16 values, and those that do may well iterate over more than 128. Also you're probably aware that modern CPUs have many more physical registers, they just don't expose them all at the same time. E.g. AMD Zen physically has 168 integer and 160 floating-point registers. Of which you can only use 16 at a time, but to my uninformed eye that looks like a reasonable trade-off.
Zaak 9y ago
If you had a "sufficiently smart compiler" you wouldn't need register renaming and instruction reordering, but such a compiler has consistently failed to appear. That's a big part of the whole Itanium fiasco. If you want your CPU to run fast, you have to pipeline instructions and you need caches that can run at full CPU speed. It's easy to design a CPU without all the complexity, but it will be slow. No one knows how to do both simple and fast. It's probably impossible.