1. Messages
  2. proposal for stateen CSRs

Re: proposal for stateen CSRs

Scott Johnson
 

Code that does environment swapping will need to use custom instructions to save custom state, so might as well use custom CSRs for the individual enable bits instead of taking up space in the standard *stateen.

The use case for the single bit is only for M-mode software that wants to enable/disable all custom state. No need to take up more than a single bit for that.

On Wed, Apr 21, 2021 at 9:41 AM Jonathan Behrens <behrensj@...> wrote:
Why does all custom state need to be controlled with a single bit? Couldn't we just designate the upper 8 or 16 bits of each xstateenY register to be custom? Any software that wanted to disable all custom state would just clear all those bits, while software that wanted to enable all custom state would just write ones. (WARL would cause any unused bits to stay zero even after they were written with a value of one).

Jonathan

On Wed, Apr 21, 2021 at 12:37 PM John Hauser via lists.riscv.org <jh.riscv=jhauser.us@...> wrote:
Allen Baum wrote:
> If I understand the above: you can write a 1 to the first bit, but you'll
> always read back zero? What does that accomplish?

It provides a convenient means for software to enable lower-privilege
access to all custom state, requiring only the minimal amount of
hardware for the task.

    - John Hauser
Join {tech-privileged@lists.riscv.org to automatically receive all group messages.