6 ms·

They got the riscv code slightly wrong (but the instruction count correct). (puts on chip designer's hat) Essentially the ARM/x64 case turns the load memory ad

They got the riscv code slightly wrong (but the instruction count correct). (puts on chip designer's hat) Essentially the ARM/x64 case turns the load memory address calculation into a 4-input adder (so 2 layers of adders) and maybe a couple of extra gates because there are multiple addressing modes. Riscv's equivalent is a 2-input adder. Those get into a critical cache (and TLB) access path and that limits how fast your CPU's core clock can be (or forces you to split that path into 2 clocks). Essentially that's part of the whole RISC idea - simple means faster - you can run your core clocks faster if the decode (and address calculations etc etc) are simpler - getting rid of lots of addressing modes was a big part of the original RISC movement. I think all 4 of those riscv instructions are 16-bit ones so they may even fit into the same space as the 2 ARM ones (haven't hacked on ARM for a while) BTW chances are that that x86_64 mov instruction is not being devolved into more than one internal uOp (might be two if they separate off the address calculation into it's own uOp)

Veedrac 6y ago
> Essentially that's part of the whole RISC idea - simple means faster - you can run your core clocks faster if the decode (and address calculations etc etc) are simpler - getting rid of lots of addressing modes was a big part of the original RISC movement. Nobody believes this anymore, not even the RISC guys. Look at Apple chips; the advantage of a simpler instruction set is width (degree and depth of superscalar execution) and the ability to put more optimizations in hardware. Clocks are all bound by roughly the same limits nowadays.
- Taniwha 6y ago
  I'd disagree - but I'm talking about the difference between a 1Ghz clock and a 5Ghz clock - it's always going to matter at the cutting edge - if the clocks are equal then what you're trading off is pipeline depth - which effects all sorts of stuff like the cost of mispredicted branches (and as a result the sizes and complexity of branch predictors)
Tuna-Fish 6y ago
> Essentially that's part of the whole RISC idea - simple means faster The problem with this is that today, your clock speed is bound by neither your decode nor your ALUs. Only implementing weaker ALUs makes sense from an optimization standpoint if it buys you more clock speed. But as it doesn't, it just leaves you competing with another CPU that has the same clock speed as you do, and which does a lot more per clock than you do.
ip26 6y ago
Turns out faster clocks don't help much if your logic isn't getting faster too. You do less work per cycle, while your cycle overhead remains fixed, resulting in less work done per unit time. If it wasn't for branch misprediction, you'd be better off with very deep pipes and slower clocks - see GPUs.
- ithkuil 6y ago
  I think the point of GP is that not every instruction makes use of the more complicated (4 input) adder, so not every instruction should have to pay for the latency cost associated. But at other pointed out this only makes sense if the ALU is the critical path and that having a two level adder significantly impacts the latency
  - Taniwha 6y ago
    Actually it's unlikely that this 4-input adder is in a general purpose ALU, usually they're directly in the cache access path (there are games you can apply to cache and TLB accesses if the low bits of that adder come out early), or in a separate addressing ALU which adds an extra clock to a load or store
    - ithkuil 6y ago
      I assume they still count towards defining the shortest possible pipeline stage duration
      - Taniwha 6y ago
        It depends on how you split it up of course, but there's another cost, if you pipeline the address calculation you effectively make the cpu's pipe longer and more importantly increase the cost of a mispredicted branch - which is where we're all spending our time trying to mitigate these days
toast0 6y ago
> Essentially that's part of the whole RISC idea - simple means faster - you can run your core clocks faster if the decode (and address calculations etc etc) are simpler How does this philosophy fare now that we're generally at the top end of feasible clock speeds for processors, given realistic power and related cooling budgets. Intel and AMD (and I assume others, but I don't follow them as closely) have been increasing throughput by doing more per clock. It would seem VLIW is the recipie for simple hardware, doing more per clock cycle; but that hasn't had good results either.
- Taniwha 6y ago
  VLIW is (IMHO, and I've built them) an architectural dead end a bit like the original MIPS delay slots it made sense at one point in one particular process, they don't scale well over time
imtringued 6y ago
x86 chips have greater top clock speeds by a significant margin. A lot of x86 cpus run in the 4-5Ghz range meanwhile ARM cpus usually stick to 2-3GHz. So the vast majority of CPU designs are not hitting their theoretical limits. They are only hitting thermal limits. The only real benefit is that fixed length instructions are easier to decode. That's about it. If you can get away with fewer instructions then that's what you should do.

Veedrac 6y ago

> Essentially that's part of the whole RISC idea - simple means faster - you can run your core clocks faster if the decode (and address calculations etc etc) are simpler - getting rid of lots of addressing modes was a big part of the original RISC movement. Nobody believes this anymore, not even the RISC guys. Look at Apple chips; the advantage of a simpler instruction set is width (degree and depth of superscalar execution) and the ability to put more optimizations in hardware. Clocks are all bound by roughly the same limits nowadays.

Taniwha 6y ago
I'd disagree - but I'm talking about the difference between a 1Ghz clock and a 5Ghz clock - it's always going to matter at the cutting edge - if the clocks are equal then what you're trading off is pipeline depth - which effects all sorts of stuff like the cost of mispredicted branches (and as a result the sizes and complexity of branch predictors)

Tuna-Fish 6y ago

> Essentially that's part of the whole RISC idea - simple means faster The problem with this is that today, your clock speed is bound by neither your decode nor your ALUs. Only implementing weaker ALUs makes sense from an optimization standpoint if it buys you more clock speed. But as it doesn't, it just leaves you competing with another CPU that has the same clock speed as you do, and which does a lot more per clock than you do.

ip26 6y ago

Turns out faster clocks don't help much if your logic isn't getting faster too. You do less work per cycle, while your cycle overhead remains fixed, resulting in less work done per unit time. If it wasn't for branch misprediction, you'd be better off with very deep pipes and slower clocks - see GPUs.

ithkuil 6y ago
I think the point of GP is that not every instruction makes use of the more complicated (4 input) adder, so not every instruction should have to pay for the latency cost associated. But at other pointed out this only makes sense if the ALU is the critical path and that having a two level adder significantly impacts the latency
- Taniwha 6y ago
  Actually it's unlikely that this 4-input adder is in a general purpose ALU, usually they're directly in the cache access path (there are games you can apply to cache and TLB accesses if the low bits of that adder come out early), or in a separate addressing ALU which adds an extra clock to a load or store
  - ithkuil 6y ago
    I assume they still count towards defining the shortest possible pipeline stage duration
    - Taniwha 6y ago
      It depends on how you split it up of course, but there's another cost, if you pipeline the address calculation you effectively make the cpu's pipe longer and more importantly increase the cost of a mispredicted branch - which is where we're all spending our time trying to mitigate these days

toast0 6y ago

> Essentially that's part of the whole RISC idea - simple means faster - you can run your core clocks faster if the decode (and address calculations etc etc) are simpler How does this philosophy fare now that we're generally at the top end of feasible clock speeds for processors, given realistic power and related cooling budgets. Intel and AMD (and I assume others, but I don't follow them as closely) have been increasing throughput by doing more per clock. It would seem VLIW is the recipie for simple hardware, doing more per clock cycle; but that hasn't had good results either.

Taniwha 6y ago
VLIW is (IMHO, and I've built them) an architectural dead end a bit like the original MIPS delay slots it made sense at one point in one particular process, they don't scale well over time

imtringued 6y ago

x86 chips have greater top clock speeds by a significant margin. A lot of x86 cpus run in the 4-5Ghz range meanwhile ARM cpus usually stick to 2-3GHz. So the vast majority of CPU designs are not hitting their theoretical limits. They are only hitting thermal limits. The only real benefit is that fixed length instructions are easier to decode. That's about it. If you can get away with fewer instructions then that's what you should do.