Clarification on Pointer Masking Extension Implementation

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

Clarification on Pointer Masking Extension Implementation #59

Closed HAMZA-AFZAL404 closed 8 months ago

HAMZA-AFZAL404 commented 8 months ago

I am currently implementing the Pointer Masking Extension in Sail and have a few questions and concerns that I would like to clarify with the community. Your assistance in addressing these queries would be greatly appreciated.

1. Setting of PMM Value:

Is the value of PMM set by the user, or is it assigned by the hardware based on VM enabled/disabled?
In the case of SV57 being enabled and PMM set to 11, what is the expected behavior(If we do the cheap implementation) ? Are there any exceptions raised?

2. PMM = 01 (Reserved):

When PMM is set to 01 (reserved), should an exception be raised, or is there a default behavior specified?

These questions arise during the implementation, and clarification on these points would greatly help in ensuring the correctness of the Pointer Masking Extension.

martinmaas commented 8 months ago

Thank you for working on this! The PMM fields are WARL; i.e., they do not result in an exception when writing an invalid value, but the invalid value will cause the field to not be updated. Regarding the specific questions:

The initial value of PMM is 0 (disabled) and will be set by the user/software.
Trying to set PMM to 11 with Sv57 is implementation specific – if this mode is supported by the hardware, then it will be the normal pointer masking behavior; otherwise the field is not updated.
PMM with 01 is an invalid write and follows WARL behavior (i.e., the value of PMM is not updated).

pdonahue-ventana commented 8 months ago

WARL; i.e., they do not result in an exception when writing an invalid value, but the invalid value will cause the field to not be updated

That's not exactly what WARL means. It just means that the read value is legal. If PMM was previously 00 and you try to write 01 (illegal), the final value might be 00 (unchanged) or it could instead be 10 or 11 (assuming those values are supported by the hardware and thus legal).

martinmaas commented 8 months ago

Good point; the behavior that I described above is not entirely due to WARL semantics – but does capture the intention: When you try to set the PMM bits to an unsupported value, the final value is the old value (as opposed to a different legal value).

I just double-checked the spec as well, to make sure this is specified there (I think it is).

HAMZA-AFZAL404 commented 8 months ago

Thanks it clears my points.

pdonahue-ventana commented 8 months ago

To clarify: My previous reply was just in reference to the sentence I quoted from this issue, not to anything said in the spec. The spec is probably fine (but I haven't looked at it in a while).

martinmaas commented 8 months ago

To clarify: My previous reply was just in reference to the sentence I quoted from this issue, not to anything said in the spec. The spec is probably fine (but I haven't looked at it in a while).

That's how I read it, and I think it is a very good point.

It looks like we can close this issue.