Re: csrrc/csrrs with mip, sip and uip

John Hauser

Simon Davidmann wrote:
The Privileged Architecture specification describes special behavior
for mip.SEIP as follows:

When mip is read with a CSR instruction, the value of the SEIP bit returned
in the rd destination register is the logical-OR of the software-writable
bit and the interrupt signal from the interrupt controller. However, the
value used in the read-modify-write sequence of a CSRRS or CSRRC instruction
contains only the software-writable SEIP bit, ignoring the interrupt value
from the external interrupt controller.
The SEIP field behavior is designed to allow a higher privilege layer to
mimic external interrupts cleanly, without losing any real external
interrupts. The behavior of the CSR instructions is slightly modified from
regular CSR accesses as a result.
I think this description needs improvement, because the intent is not
fully clear for SEIP , or other bits. In particular:
1. What about other set-pending bits that are writable by software?
For example, if the N extension is implemented, how do mip.UEIP and
sip.UEIP behave?
The section you are quoting, 3.1.9, "Machine Interrupt Registers (mip
and mie)", says nothing about the N extension. If you look at the
figures for the mip register in that section, there is no UEIP bit
there. If the N extension's UEIP bit should have any special behavior,
the place for this to be specified would be the chapter on the
N extension, the same place where UEIP is first introduced.

As far as UEIP is concerned, I think your real complaint is that the
chapter on the N extension has never been completed or maintained.
I believe many of the principal movers are no longer interested in
developing or promoting this extension. For the N extension chapter to
be completed, somebody has to step up who wants this to be done. (My
own personal opinion is that we should drop the N extension.)

As to the bits of mip defined in section 3.1.9, I think the fact that
the document spells out a special case explicitly for SEIP and does not
do the same for any other bits in mip should be ample evidence that the
special case applies only to SEIP and not to any other bits defined for
mip in that section.

2. For which bits does any externally-asserted interrupt contribute
to the result seen in rd for csrrc or csrrs ? For example, would the
external value of mip.SEIP contribute to rd in this case, or is just
the software-writable bit value seen?
The value that a CSR instruction reads from mip into the instruction's
rd destination is not affected by which CSR instruction does the read,
whether it's CSRR, CSRRW, CSRRC, or CSRRS. In all cases, externally
asserted interrupts for bits MEIP and SEIP show up in the value written
to the rd destination.

As a general case, imagine that:
1. A system using the N extension is being used;
2. All interrupts are delegated to their lowest possible privilege
level using mideleg and sideleg ;
3. All interrupts are disabled;
4. Interrupts MEI , SEI , UEI , MTI , STI and UTI are all asserted
externally (so csrr t1, mip returns 0xbb0 ).
5. No software pending bits are set for these interrupts.

Given the above set up, what value is observed in t1 in each of these
cases: [...]
As this question involves the N extension, I'll leave it others to say
how they think the N extension should be defined.

If you'd like to ask about a different example that doesn't involve the
N extension, I can try to answer.


- John Hauser

Join to automatically receive all group messages.