M bit sense should be inverted #34
Comments
|
I don't agree - on a purecap only core the M bit doesn't exist - it's reserved - and could be used for something else in future. This is unlikely on RV64 as there's a lot of free space in the metadata, but for RV32 this is extremely likely as there are very few reserved bits, and more extensions are planned. The immediate need is to add some CHERIoT style features which will be for a purecap only core which will use that bit for something else, which is why we separated it out. So software for a purecap only core must not be relying on the state of that bit. |
|
I am not proposing for purecap software to rely on the state of the bit, or look at the bit at all. Purecap software sets all reserved bits to 0, so extensions should do something with the value "0" that is appropriate for purecap. Software that uses a given extension will set its corresponding allocated bits to "1". |
That doesn't work; if the bit exists it needs to be set to the right value! Which makes 0 the sensible value to use in this world, so you don't have to do anything to get the right value by default. Only if you want legacy mode do you need to set it to 1. |
|
My thoughts on the matter have shifted to "capability extensions can redefine the format of the metadata word within fairly broad limits, so although it is architectural software should treat the metadata word format as implementation defined unless the exact ISA string is known; cbuildcap should not be used in generic software on anything other than a bit pattern previously generated by the implementation". If that is adopted, this issue can be closed. |
We now have three models for the implementation of MODESW: storing the mode in the pcc metadata, as ISAv9, storing the mode in the pcc LSB, as Morello, and storing the mode in a loosely associated bit. Using the metadata is robust but uses a scarce metadata bit (especially on RV32) for a bit with extremely low entropy, since legacy code by definition does not make heavy use of code capabilities. Storing the mode in the address LSB is superficially attractive, since it is unused for code capabilities, but it is incompatible with existing RISC-V design decisions (silently masking LSB on legacy mode jalr and writes to xepc). Were it made possible to use the LSB of function pointers and return addresses in that way, it would be most useful for mode switches which do not affect the ABI and can be mixed freely at the level of possibly indirect calls. We have two very different ABIs and only one useful instruction set for each ABI, so there is little to be gained by decoupling the ABI from the implementation instruction set of a function. Assuming, then, that the entry instruction set of a function is determined by the ABI used to call it, it is natural to decouple the choice of instruction set from the function address. We define in this proposal that code which is jumped to via a capability always uses Capability mode; to jump to code in Legacy mode, use a trap return or a trampoline within the legacy pcc bounds. By requiring trap handlers to use Capability mode and not storing mode metadata for CSRs other than xepc, this proposal achieves the smallest architectural state of the three options, only 4 bits for D+M+S+U. Fixes riscv#31. Fixes riscv#34. Fixes riscv#63. Signed-off-by: Stefan O'Rear <sorear@fastmail.com>
|
The sense of the M-bit has already been inverted: #305 |
In Zcheri_purecap, M is a reserved bit, so Zcheri_purecap software will set M to 0. For this reason, if Zcheri_mode is enabled, M = 0 should trigger Zcheri_purecap-compatible behavior, with M = 1 used for the non-Zcheri_purecap-compatible behavior.
The text was updated successfully, but these errors were encountered: