News for hackers. Stuff that matters.
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.