Hi, Was any consideration given to the possibility of defining stimecmp as a memory-mapped register (like mtimecmp) rather than a CSR? Assuming that the timer will actually be implemented in a block

Greg, Thanks. That’s great explanation. RR

Actually, I realize that I was imprecise and probably flat out misleading. Address calculations (e.g. by load/store instructions) are performed to full XLEN size, producing a full XLEN-wide value

Thanks for the response, Greg. To make sure I understand, are you saying that when in M-mode/Bare-mode, addresses generated by s/w should be zero-extended from their implemented PA size up to

Architecturally addresses are always XLEN in size. PA's are unsigned values and are zero-extended from their implemented size up to XLEN size. Those extra bits may not physically exist, but they do

In RISC-V, instruction fetch addresses and load and store effective addresses are XLEN bits wide; however, an implementation can have a smaller physical address size. When a core is in M-mode or Bare

I think the fact that the current platform spec draft lacks any way for S-mode to toggle misa.H, for S-mode to request a specific value, or even a way for configuring M-mode to set/unset misa.H at

Without a doubt, there’s value in building machines that can faithfully emulate less-capable machines. With that in mind, writable misa.H is a well architected feature. Whether it rises to the level

Disabling FP and Vector units (or any extension that adds a lot of user-privileged stage) can be useful for lazy context switching, but that should be done via mstatus.FS/XS rather than misa bits.

I don't disagree. Which begs the question of whether there should be any encouragement or expectation that any implementations (barring inevitable exception cases) of misa should have writable bits.

Thanks Andrew and Gregg. I'll ask the question on unixplatformspec. Cheers, Phil

My own (possibly unpopular) take is that implementing writable misa.H is a mess, and the benefits don’t come close to justifying the effort.

Phil, Yes, this would be a good question for the platforms (not profiles) group to discuss . I'll go ahead and raise it to the group. The H extension does explicitly "encourage" implementations to

I recommend visiting the tech-unixplatformspec mailing list. The profile and platform specs are far from being frozen, and so your input may well be impactful.

Hi, Does anyone know why the RV22A profile draft (https://github.com/riscv/riscv-platform-specs/blob/main/riscv-platform-spec.adoc) mandates the following: misa If the H extension is supported

Paul Donahue wrote: You have the effect of "HS-qualified" backwards. An instruction raises a virtual instruction exception _only if_ it is HS-qualified. If it isn't HS-qualified, then it must raise

I invite comment on this proposed update to the rules for raising virtual instruction exceptions when in VU mode: https://github.com/riscv/riscv-isa-manual/pull/730 - John Hauser

Paul Donahue wrote: From the hypervisor extension chapter, Section 5.2, "Hypervisor and Virtual Supervisor CSRs": Some standard supervisor CSRs (scounteren and scontext, possibly others) have

Explicitly cc'ing John on this H extension oriented question.

scounteren's effect on VU-mode is unclear. VU-mode accesses to HPMn do not necessarily have "insufficient privilege" since hpmcountern is listed in table 2.2 as requiring user privilege. Is