Date
1 - 4 of 4
csrrc/csrrs with mip, sip and uip
|
We posted this on https://groups.google.com/a/groups.riscv.org/g/isa-dev/
but had no response in 2 weeks - so maybe this is a better place: Looking forward to a response. Simon The Privileged Architecture specification describes special behavior for mip.SEIP as follows:
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?
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?
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:
(Note that no CSR state is changed by these instructions - only the result in t1 is of interest.)
And given the same set up, which (if any) software-writable bits are set by these instructions:
li t0, 0 (In other words, what externally-asserted interrupt signal values are propagated to software-writable bits?)
Thanks.
|
|
|
|
John Hauser
Simon Davidmann wrote:
The Privileged Architecture specification describes special behaviorThe 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 contributeThe 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: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. Regards, - John Hauser |
|
|
|
You say "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. " but the priv spec (from July, anyway) says: 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. If you interpret "value used" as the value read and returned in Rd, then the value read does differ. If you interpret "value used" as the value written into the software-writable bit, then it doesn't. The problem here is how to interpret "used", and I interpreted is as it was used (sorry) in the previous sentence. Normally, I would expect to execute CSRRC to clear the existing pending bit, but to OR in any incoming interrupt into the SW writeable bit order not to lose it. Your interpretation can cause an incoming interrupt to be lost. I think the wording here needs to be updated to remove any possible ambiguity. On Thu, Aug 13, 2020 at 12:14 PM John Hauser <jh.riscv@...> wrote: Simon Davidmann wrote: |
|
|
|
John Hauser
Allen Baum wrote:
When mip is *read* with a CSR instruction, the *value* of the SEIP bitThe interpretation is supposed to be the second one. Normally, I would expect to execute CSRRC to clear the existing pendingActually, no, for two reasons: First, supervisor-level interrupts are normally handled in S mode, and bit SEIP isn't writable in sip. And obviously S mode can't touch mip. So, a supervisor-level OS can't clear the pending interrupt by clearing sip.SEIP; it doesn't have that ability. Second, for M mode, the incoming external interrupt for SEIP is not affected by a write to mip, only the software-writable bit is. So, only the software-writable interrupt could possibly be "lost" this way, not the externally sourced interrupt. I put _lost_ in quotation marks because the only reason to write to clear mip.SEIP is to intentionally clear the software-writable bit. If that's the intention, then the "loss" of that interrupt isn't an accident. I think the wording here needs to be updated to remove any possibleI won't disagree. - John Hauser |
|
|