Date
1 - 3 of 3
FYI: ARM vs. RISC-V vector extension conmparison
Yeah. I posted this link to our reddit /r/riscv four weeks ago and made a few comments about it. It was posted on Hacker News yesterday and both Chris BOOM! Celio and I made a few comments and replies: I have since at the author's request pointed him at the current spec. > Rather superficial - all about how hard it is for a person to program in assembly language, rather than how a compiler can take advantage of the encoding. In one HN comment I pointed out that while having scaled indexed addressing mode for your vectors can be nice, those extra bits in a fixed size opcode do come at a cost. > On a quick reread, I see a complaint that's entirely due to how > ARM represents indexed load operations, which has absolutely > nothing to do with the vector ISA whatsoever. Not exactly true. If you can use fancy addressing modes in your vector loads and stores and you have a fixed length 32 bit opcode (as both Aarch64 and RISC-V do[1]) then specifying an index register and how much to shift it by is taking up an extra 7 bits of your opcode (5 for register number, 2 for shift amount) vs an instruction that just specifies a base pointer register. That means one instruction is taking up the opcode space that could otherwise be used by 128 different instructions instead. That means either your vector ISA has fewer instructions and capabilities than it otherwise could have, or else it is taking up a lot more of the overall opcode space. On Sat, May 8, 2021 at 9:07 AM Allen Baum <allen.baum@...> wrote:
|
|
I guess the publicity doesn't hurt, but I do wish the author had considered our developments here (at riscv/riscv-v-spec). His material appears to derive from Patterson-Waterman's 2017 book (and sigarch blog-post), and the architecture has evolved a bit since. On Fri, May 7, 2021 at 5:06 PM Allen Baum <allen.baum@...> wrote:
|
|
Rather superficial - all about how hard it is for a person to program in assembly language, rather than how a compiler can take advantage of the encoding. |
|