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.
[ Parent
| on HN ]
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.