News for hackers. Stuff that matters.
Re:Addressing Criticism of RISC-V Microprocessors by TazeTSchnitzel on Sunday March 20, 2022 @04:04AM (#30740980)
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.
Re:Addressing Criticism of RISC-V Microprocessors by fay59 on Sunday March 20, 2022 @04:25AM (#30741060)
All of the ARM assembly is wrong. AArch64 uses “x” or “w” to identify general purpose registers, “r” isn’t a thing.
Re:Addressing Criticism of RISC-V Microprocessors by solarexplorer on Sunday March 20, 2022 @06:42AM (#30741588)
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.
Re:Addressing Criticism of RISC-V Microprocessors by brucehoult on Sunday March 20, 2022 @07:48PM (#30748072)
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.

Re:Addressing Criticism of RISC-V Microprocessors by znwu on Sunday March 20, 2022 @09:31PM (#30748997)
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.
Re:Addressing Criticism of RISC-V Microprocessors by snvzz on Sunday March 20, 2022 @10:38PM (#30749486)
The actual hardware cost of this case of "macro-op fusion" is negligible.
Re:Addressing Criticism of RISC-V Microprocessors by znwu on Wednesday March 23, 2022 @04:11PM (#30782731)
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.

Re:Addressing Criticism of RISC-V Microprocessors by snvzz on Wednesday March 23, 2022 @06:34PM (#30784435)
macro-op fusion is not rocket science.
Re:Addressing Criticism of RISC-V Microprocessors by znwu on Thursday March 24, 2022 @06:44AM (#30788138)
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.

Re:Addressing Criticism of RISC-V Microprocessors by pxeger1 on Sunday March 20, 2022 @04:48PM (#30746471)
I thought it was only supposed to be pseudo-assembly?