[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 #6 from paulus at ozlabs.org ---
"Definition of Reserved" section:

I have reservations about this. Generally in the architecture if you want this
behaviour of taking a HEAI (Hypervisor Emulation Assistance Interrupt) on
things that aren't recognized, you define an instruction field to cover the
bits and specify a set of defined values for it. Then any other value in the
field becomes a reserved value for the field (Book I section 1.3.3), and an
instruction containing a reserved value in a defined instruction field is an
invalid form. Book III section 7.5.18 then says that a HEAI may be generated
when execution of it is attempted.

However, experience has shown that it is often more useful to define reserved
fields, which must be ignored by the processor. We got into trouble with
mfocrf, which was introduced in POWER4, because POWER3 didn't ignore reserved
fields. The mfocrf instruction looks similar to mfcr except that it has
non-zero values in some bits that were reserved in the pre-POWER4 definition of
mfcr, and mfocrf was defined such that doing what mfcr does is an acceptable
implementation of it. Thus if POWER3 had correctly ignored reserved instruction
fields, we could have started using mfocrf in binaries without worrying about
whether they might get run on a POWER3 or not. Instead, we had either to avoid
mfocrf (missing optimization opportunities on POWER4 and later) or include
alternate code paths for POWER3 vs. >= POWER4 (which adds overhead).

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). 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.)

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