Major Changes at RISC-V Designer SiFive

Re:Major Changes at RISC-V Designer SiFive by mort96 on Tuesday October 24, 2023 @08:11AM (#37997995)

I'm wondering what part you call "architectural purism" here. Spending a whole lot of opcode space on a set of compressed instructions doesn't strike me as an especially purist solution to the code size problem, and if what camel-cdr suggests in https://news.ycombinator.com/item?id=37997077 is correct, then Qualcomm's solution is also pretty much a set of 16-bit compressed instructions, but where the 32-bit instructions must be 32-bit-aligned, which strikes me as neither significantly more nor significantly less pure than the current C extension.

To me, this looks like a reasonable argument over design decisions, where there are clear advantages and disadvantages to either side. It's basically a trade-off between code size and front-end complexity. Can you detail where exactly you see the purism thing being an issue?

[ Parent | on HN ]

Re:Major Changes at RISC-V Designer SiFive by fidotron on Tuesday October 24, 2023 @08:35AM (#37998257)

I believe Qualcomm are proposing dropping 16 bit instruction support, exactly like Aarch64.

[ Parent | on HN ]

Re:Major Changes at RISC-V Designer SiFive by mort96 on Tuesday October 24, 2023 @09:47AM (#37999126)

You seem to be right. I had interpreted some other responses in this thread to mean that Qualcomm has their own alternative 16-bit encoding that doesn't have the 32-bit instruction alignment issue, but it seems like they instead have a whole bunch of new 32-bit instructions which have memory operands and a bunch of addressing modes.

I see now what you mean by posing this as a conflict between ISA purists (only provide load/store all other instructions have register or immediate operands, only provide one store and one load instruction, add compressed instructions to combat binary bloat) and ISA pragmatists (add new special-case instructions with memory operands and useful addressing modes).

[ Parent | on HN ]