3 ms·
To these I would add: lack of a rotate instruction in the base ISA, and unix standard extension groups. This makes symmetric key encryption and most hash functi
by bem94 7y ago
To these I would add: lack of a rotate instruction in the base ISA, and unix standard extension groups. This makes symmetric key encryption and most hash functions much slower. The Bitmanip extension has a rotate instruction, but it should have been in the base ISA.
I'd also emphasise the lack of indexed load/store instructions again. It is a disaster for any sort of array indexing where you're addressing >1 array using the same index. I found this in the context of multi-precision arithmetic for crypto, but examples come from all over.
On the author's point about multiply and divide in the same extension: crypto is another good example. Lots of crypto really benefits from multiply, but doesn't need divide.
The most important thing about RISC-V is the idea behind it's openness as a standard and the ecosystem around that standard. The engineering of the ISA itself is not what makes it remarkable, and actually leaves a lot to be desired.
- brucehoult 7y agoI see the word "crypto" in each of your objections. While crypto is important, it's not the whole world and not everyone needs the absolute fastest crypto possible. If you do, then use a processor with crypto instruction extensions. If not, you can get by just fine with the operators C gives you. Most software doesn't use rotate operations. When you do need one, it takes three instructions to synthesize it if the shift count is a constant, or four otherwise. Unless you're doing nothing but rotates you're not going to notice it. If you're doing any memory loads that miss in the L1 cache to get the data you're rotating then you're also not going to notice it. The same goes for the indexed loads and stores. Measure it, don't just go on your feels. The main problem with the the original post is that the author criticizes things based on his sense of aesthetics, and what he's used to, not on any kind of actual scientific experimentation and measurement of different options. The whole premise of H&P's "Computer Architecture: A Quantitative Approach" is that you should base decisions about what to put into your hardware and what to leave out based on actual data, not on what seems prettier or more orthogonal to you.