search

riscv / riscv-j-extension

Working Draft of the RISC-V J Extension Specification
https://jira.riscv.org/browse/RVG-128
Creative Commons Attribution 4.0 International
162 stars 17 forks source link

Pointer Masking ISA three extensions: why? #48

Closed ingallsj closed 1 year ago

ingallsj commented 1 year ago

I see the rationale for splitting this out into the three extensions Ssnpm, Smnpm, Smpm, but this just seems like needless complexity. Do we have a use case where only a subset of these three would be implemented, that can't be defined more concisely?

https://github.com/riscv/riscv-j-extension/blob/ac6782d43813a8674a4704ff01ef00555dfe73d1/zjpm/background.adoc?plain=1#L150-L156

Note: I still agree with the CSR controls for each level; I'm just proposing that they all fall under one extension.

martinmaas commented 1 year ago

This was an ask by the architecture review committee. My personal take is that this organization could be helpful for custom (e.g., embedded) systems that do not use a standard profile (I expect that RVA profiles will likely mandate all three):

1) A system may only want to provide pointer masking in user mode (e.g., because it is used for application debugging or to support managed runtimes, which do not typically run in kernel mode).

2) A system may choose to not implement M-mode pointer masking since it requires logic that is different from the logic used by U and S-mode pointer masking.

The flexibility of allowing these use cases seems worth the (moderate) complexity.

ingallsj commented 1 year ago

Grumble. I would've assessed the trade-off differently of whether that's worth the complexity.

A common critique of RISC-V is the proliferation of extensions becoming unwieldy (answer: profiles, I know), and this being split into three doesn't help the matter. But, whatever, I'm not on the ARC.