10 ms·

The conditional execution section makes no mention of the fact AArch64 doesn't have this feature either, and bizarrely lists a “64-bit” ARM code example that is

The conditional execution section makes no mention of the fact AArch64 doesn't have this feature either, and bizarrely lists a “64-bit” ARM code example that isn't. This doesn't inspire confidence in the author's understanding.

fay59 5y ago
All of the ARM assembly is wrong. AArch64 uses “x” or “w” to identify general purpose registers, “r” isn’t a thing.
solarexplorer 5y ago
In the same section the part about the SiFive optimization is also misleading. The goal of the optimization is obviously to avoid interrupting the instruction fetch. But he makes it sound like the goal was to reduce instruction count by fusing two instructions to get a single monster op with five (!) register operands. That just doesn't make sense.
- brucehoult 5y ago
  They don't fuse it. They have the branch and the following instruction both go down one integer pipeline just as they would if the branch was predicted "not taken. They are linked/tagged together such that if the branch actually happens then the result from the second instruction is simply not written back instead of taking a branch mispredict. So the four input operands and one output operand are not a problem because that's just what two pipelines do all the time anyway.
pxeger1 5y ago
I thought it was only supposed to be pseudo-assembly?
znwu 5y ago
Yes, the author's defence for Myth #1 does not strike me as a correct defence from the RISC-V perspective. Going to compressed instruction and compressed macro-op fusion is way overkill for the very basic indexed load/store problem.
- snvzz 5y ago
  The actual hardware cost of this case of "macro-op fusion" is negligible.
  - znwu 5y ago
    Yes it is negligible. The problem is that indexed load/store is a non-issue. There are ready-to-use simulation data that shows indexed load/store has minimal impact on dynamic code size.If someone uses an overkill feature to explain a non-issue, then it seems like nonsense. Imaging someone uses quantum gravity to explain why Australians stand upside down on a globe.
    - snvzz 5y ago
      macro-op fusion is not rocket science.
      - znwu 5y ago
        Then write up an actually meaningful array processing function and translate it into asm is even less rocket science. The author starts with a apparently meaningless `int x = a[i];`, but did not ask an obvious question before digging in: what usually goes before and after this statement and together what will they produce? A formal RISC-V code analysis usually does not go like this. `int x = a[i];` is the kind of expression that strikes you as useful at the first glance, but then nothing. If you visit an array, then on x64/ARM/RISC-V, they are all compiled down to 2 instructions per iteration. Not 1 vs 2 vs 3 as suggested by the article. RISV-V may have one or two more instructions outside the loop but that's it.

fay59 5y ago

All of the ARM assembly is wrong. AArch64 uses “x” or “w” to identify general purpose registers, “r” isn’t a thing.

solarexplorer 5y ago

In the same section the part about the SiFive optimization is also misleading. The goal of the optimization is obviously to avoid interrupting the instruction fetch. But he makes it sound like the goal was to reduce instruction count by fusing two instructions to get a single monster op with five (!) register operands. That just doesn't make sense.

brucehoult 5y ago
They don't fuse it. They have the branch and the following instruction both go down one integer pipeline just as they would if the branch was predicted "not taken. They are linked/tagged together such that if the branch actually happens then the result from the second instruction is simply not written back instead of taking a branch mispredict. So the four input operands and one output operand are not a problem because that's just what two pipelines do all the time anyway.

pxeger1 5y ago

I thought it was only supposed to be pseudo-assembly?

znwu 5y ago

Yes, the author's defence for Myth #1 does not strike me as a correct defence from the RISC-V perspective. Going to compressed instruction and compressed macro-op fusion is way overkill for the very basic indexed load/store problem.

snvzz 5y ago
The actual hardware cost of this case of "macro-op fusion" is negligible.
- znwu 5y ago
  Yes it is negligible. The problem is that indexed load/store is a non-issue. There are ready-to-use simulation data that shows indexed load/store has minimal impact on dynamic code size.If someone uses an overkill feature to explain a non-issue, then it seems like nonsense. Imaging someone uses quantum gravity to explain why Australians stand upside down on a globe.
  - snvzz 5y ago
    macro-op fusion is not rocket science.
    - znwu 5y ago
      Then write up an actually meaningful array processing function and translate it into asm is even less rocket science. The author starts with a apparently meaningless `int x = a[i];`, but did not ask an obvious question before digging in: what usually goes before and after this statement and together what will they produce? A formal RISC-V code analysis usually does not go like this. `int x = a[i];` is the kind of expression that strikes you as useful at the first glance, but then nothing. If you visit an array, then on x64/ARM/RISC-V, they are all compiled down to 2 instructions per iteration. Not 1 vs 2 vs 3 as suggested by the article. RISV-V may have one or two more instructions outside the loop but that's it.