grayresearch
commented
7 months ago The new mcx_selector.cte (custom operation trap enable) introduced in #32 will cause each custom instruction or custom CSR access to raise an illegal instruction exception. This enables software emulation of both legacy custom extensions', and composable extensions', custom instructions and custom CSRs.
Presently the spec %2.2.2 proposes uniform error signaling using a new custom user-read/write CSR called cx_status. It is analogous to fcsr CSR for accumulating floating-point errors.
After CX multiplexing is enabled by a write to mcx_selector (possibly indirectly via a write to cx_index), various CX-related errors are accumulated in cx_status, including:
The present programming model is discover the extension is configured on the CPU, select it (write its cxu_id and state_id to mcx_selector), zero cx_status, perform some series of CX instructions, check cx_status is still zero.
This is all well and good and simple and logic frugal. Hardware-wise it is less expensive than raising a precise exception on the custom instruction to signal the error. However, it is unhelpful if you are trying to develop a CX library for a CX/CXU that is not configured on your test system.
Instead, imagine if instead of, or in addition to, setting error flags in cx_status, for conditions .IV, .IC, .IS, .OF, and .IF the processor signaled an invalid instruction exception, precisely at the CX custom instruction that caused it. Then the absent CX, CX state context, or CX instruction, could be emulated in a custom instruction trap handler. Indeed we could provide a standard uniform way to package a software emulation library for a CX, enabling development of CX libraries even on systems where that CX is not configured.
This seems appealing but it causes significant downstream effects. For example if a CX custom instruction, even a stateless one, can now cause an illegal instruction exception, it further motivates a more complex CXU-LI that supports speculative execution and drives additional complexity into a CPU core to handle the case that the CXU takes an arbitrary number of cycles to signal a condition that leads to an illegal instruction exception, such that instructions in the wake of that CX custom instruction exception must be annulled.
Having written this up, I am not convinced the complexity of the illegal instruction exception justifies the additional utility it provides. What do you think? Thank you.