Few Queries on Privilege modes RISCV

[Abhav S Velidi]

Hi,

had some few queries while implementing privilege mode..

1) Do each privilege mode get its own set of general purpose registers like in case of ARM, if not is the same register set shared by all the privilege modes.

2) When an interrupt or a exception occurs in M-mode and delegates to S-mode who sets the value of scause register, i.e does the hardware copy the value of mcause register into scause register, or is there any other mechanism.

3) Is the mscratch and sscratch registers base address initialized during boot up? and when a trap occurs does the hardware store the general purpose registers to the to the address pointed by the scratch register or does the software store these register values.

[Tommy Murphy]

1) Do each privilege mode get its own set of general purpose registers like in case of ARM

No.

 

if not is the same register set shared by all the privilege modes.

Yes.

 

2) When an interrupt or a exception occurs in M-mode and delegates to S-mode who sets the value of scause register, i.e does the hardware copy the value of mcause register into scause register, or is there any other mechanism.

From the Privileged Spec:

* https://riscv.org/technical/specifications/

>  4.1.8 Supervisor Cause Register (scause) The scause register is an SXLEN-bit read-write register formatted as shown in Figure 4.11. When a trap is taken into S-mode, scause is written with a code indicating the event that caused the trap. Otherwise, scause is never written by the implementation, though it may be explicitly written by software.

 

3) Is the mscratch and sscratch registers base address initialized during boot up?

Not by hardware. Depending on the OS used the bootloader or OS may initialize it. Again from the Privileged Spec:

>  3.1.13 Machine Scratch Register (mscratch) The mscratch register is an MXLEN-bit read/write register dedicated for use by machine mode. Typically, it is used to hold a pointer to a machine-mode hart-local context space and swapped with a user register upon entry to an M-mode trap handler.

>  4.1.6 Supervisor Scratch Register (sscratch) The sscratch register is an SXLEN-bit read/write register, dedicated for use by the supervisor. Typically, sscratch is used to hold a pointer to the hart-local supervisor context while the hart is executing user code. At the beginning of a trap handler, sscratch is swapped with a user register to provide an initial working register.

 

and when a trap occurs does the hardware store the general purpose registers to the to the address pointed by the scratch register or does the software store these register values.

Again the Privileged Spec should clarify what the hardware does with these. Otherwise it depends on the nature of the OS used.

 

[Allen Baum]

I'm not sure I would agree that the spec should say what doesn't happen, as opposed what does happen.  

so for #1 - the spec doesn't say, so it doesn't happen.

For #2: Another way to look at this is that  the delegation CSRs determine which mode will handle the trap. 

   Only then are the xTVAL, xCAUSE, xEPC, xIP, etc CSRs written, so only one of them is written - 

nothing gets transferred from one to the other. 

For #3, the spec is pretty clear about which CSRs must have specific reset values (as well as GPRs).

There aren't very many... and again, if the spec doesn't say anything about a reset value, then no reset value can be assumed

(and implementations can set them to anything they want)

I will admit that there is a little ambiguity about the phrase.    "at the beginning of the trap handler, sscratch is swapped..." in sec 3.1.13 and 4.1.6

 because that could be interpreted to mean *before* the first instruction of the trap handler, as opposed to instructions *inside* the trap handler, 

This is made more ambiguous by "is swapped" rather than "software should swap" .

It isn't a requirement that they be swapped in HW or SW (though you won't be able to safely RET if you don't).

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/50fbc61d-995c-4eea-b6f4-af8168eb8f4dn%40groups.riscv.org.

[Abhav S Velidi]

Thank you all for replying,

I have another query regarding the stack pointer, base pointer.
When we talk about arm architecture each mode has its own set of stack pointer and base pointer, Is it the same in the case of RISCV? Does each mode get its own set of stack pointer and base pointer registers? If not where and how are the previous values of the stack pointer and base pointer stored when a switch happens to another mode ( Say from U-mode to M-mode)?

[Bruce Hoult]

> I will admit that there is a little ambiguity about the phrase.    "at the beginning of the trap handler, sscratch is swapped..." in sec 3.1.13 and 4.1.6

> because that could be interpreted to mean *before* the first instruction of the trap handler, as opposed to instructions *inside* the trap handler, 

> This is made more ambiguous by "is swapped" rather than "software should swap" .

> It isn't a requirement that they be swapped in HW or SW (though you won't be able to safely RET if you don't).

There is also no requirement to use mscratch or sscratch in this way at all. A handler could perfectly well save one or more registers to static locations at offsets from the ZERO register or GP or some other register you decide to reserve for that purpose. Or you could use a convention that a few registers such as s8-s11 are never used by anything except interrupt code (it is easy enough to tell gcc not to use them) so they never need to be saved at all.

This is in the context of bare metal programming, or writing your own OS/ RTOS of course, not a standard hosted environment. And you'll have to be careful of nested interrupts.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAF4tt%3DB_Gs-9ysf_cs%2B6d9s7URbNVeCyrDXcUVKcwDwFqdJrfw%40mail.gmail.com.

[Bruce Hoult]

The RISC-V instruction set does not specify a stack pointer or a base pointer. AT ALL. The hardware does not have any such concept. Software can use any X register it wants to as "the" stack pointer. Except X0, obviously.

The hardware does NOTHING to any X register or F register or V register when a switch happens to another mode. NOTHING. The hardware only makes changes to CSRs and to the PC as specified in the manual, and earlier in this thread. i.e. PC -> xEPC or xEPC -> PC and so on.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/45a9d1c2-b8e7-40b9-8937-52ed56474f35n%40groups.riscv.org.

[L Peter Deutsch]

> The RISC-V instruction set does not specify a stack pointer or a base
> pointer. AT ALL. The hardware does not have any such concept. Software can
> use any X register it wants to as "the" stack pointer. Except X0, obviously.

The C extension strongly favors the use of x2 as a stack pointer, although
that is only for code size (and likely speed) optimization, not
functionality. Aside from that, what you said.

--

L Peter Deutsch :: Aladdin Enterprises :: Healdsburg, CA & Burnaby, BC

[Bruce Hoult]

Well, let's say the C extension allows 2 byte opcodes to be used for full-register loads and stores at larger (aligned) offsets when using x2 as the base register compared to other registers. That turns out to be handy if you are using x2 as a stack pointer for spilling and reloading many registers, but other uses can be imagined.

That might well be a good reason to load the pointer for your trap handler register save code's save area into x2 (from scratch or elsewhere) rather than into x23, but that doesn't imply that it's a stack.

And, as you say, you can safely ignore all that and just get slightly bigger code.

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/20230713125004.01DCCEC21D2%40serpent.at.major2nd.com.