[Libre-soc-isa] [Bug 1056] questions and feedback (v2) on OPF RFC ls010

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=1056

--- Comment #20 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Paul Mackerras from comment #6)

> 
> Also, the requirement for a trap when writing ones to reserved bits in SPRs
> is problematic. At the very least you need to exempt privileged code from
> this requirement (to avoid taking traps in context-switch code, where it is
> often quite difficult to handle traps sanely). 

on the basis that supervisor code (fragile as this is) could end up
in recursive trap hell, which is really important to avoid

https://www.st.com/resource/en/reference_manual/rm0004-programmers-reference-manual-for-book-e-processors-stmicroelectronics.pdf

by chance i encountered some relevant wording on this in VLE Book 3.18.1

Invalid SPR references

System behavior when an invalid SPR is referenced depends on the privilege
level.

* If the invalid SPR is accessible in user mode (SPR[5] = 0), an illegal
instruction exception is taken.
* If the invalid SPR is accessible only in supervisor mode (SPR[5] = 1) and the
core complex is in supervisor mode (MSR[PR] = 0), the results of the attempted
access are boundedly undefined. 
* If the invalid SPR address is accessible only in supervisor mode (bit 5 of an
SPR number = 1) and the core complex is not in supervisor mode (MSR[PR] = 1), a
privilege exception is taken. These results are summarized in Table 58. 

       Table 58. System response to an invalid spr reference SPR address bit
5MSR[PR]Response 0 (User)xIllegal exception 1 (Supervisor) 0
(Supervisor)Boundedly undefined 1 (User)Privilege exception

> I would strongly suggest
> specifying that the HEAI is to be taken when executing the next SVP64
> instruction, rather than on the mtspr. (If you do insist on it being taken
> on the mtspr then you will need to add a case to Book III section 7.5.18.)

no i agree the supervisor is off-limits (unless hypervisor could
handle it and even then the problem is simply "moved to HV" sigh)

for context: the Looping system *really is* an independent concept
critically and orthogonally relying on *Scalar* instructions only.
if there is anything in the spec that appears to imply otherwise then
it should immediately be assumed to be wrong, and i need to know where
so i can correct it.

therefore the guiding principle should be taken that the only changes
should be those that minimally get SimpleV Looping into the ISA,
but not at the expense of crippling it and its future interoperability
and expandability.

-- 
You are receiving this mail because:
You are on the CC list for the bug.