On Mon, Oct 7, 2013 at 8:15 AM, Stefan Kristiansson < [email protected]> wrote:
> On Sun, Oct 6, 2013 at 10:10 PM, Peter Gavin <[email protected]> wrote: > >> Ok, I've added the things already described to the wiki. >> >> I have a few other concerns: >> >> > As always, you raise valid concerns that we others seem to oversee. > I suppose I tend to spend a lot of time focused on the details :) Also, I'm working on finishing up my delay-slot-less version, and there are some things not quite clear from the manual or from or1ksim. I suppose I should use mor1kx as a reference as well. I'm currently tidying up exception and SPR handling, and I've been trying to bring up any ambiguities I find so they can be ironed out in the manual. > > I think it makes most sense that FO would be stuck to 1 in ESR as well. > > >> It seems like only the relevant bits in SR should be storable in ESR, and >> any bits that are ignored or are fixed should be able to be ignored. >> Similarly, can the least significant 2 bits of the EPCR register be fixed >> to zero? >> >> > And I agree here, I think it should be possible to do what you propose > here. > > >> Why is the PPC register writable according to table 4-2? What happens >> when it's written to? >> >> > I can't come up with an use case where it would be of use to be able to > write it and mor1kx doesn't support writing to it. > Ok, so I'll write up a few things on the wiki about these things. Essentially: bits that are fixed in SR (such as FO, and CID when fast exceptions aren't available) are also fixed in ESR0. PPC is read-only. EPCR[1:0] is fixed to zero. One other thing: it makes more sense to me to leave the initial values of ESR, EEAR, and EPCR undefined by the standard, instead of using the current value of zero. If reset is treated like any other exception, ESR and EPCR should reflect the state following the most recently completed instruction. However, the "most recently completed instruction" doesn't actually exist at reset time, so that rule can't be applied. And, in any case, I don't think l.rfe should (or would) ever be called unless it's at the end of a normal exception handler, or with ESR and EPCR having been written to first (e.g., switching contexts). Requiring that they be initialized to zero at reset requires additional logic that seems mostly unnecessary, in order to handle an event that occurs exactly once. Interesting question, and again I don't have a good answer, but in mor1kx > the only case where it would > trigger an alignment exception would be if you stall the processor, write > NPC over debug if and unstall the processor. > Because that's the only case where NPC is fed back to the fetch unit. > I think you can disregard the case where actual software would write NPC, > because even though it's > possible to write it via the mtspr instruction, it's not "allowed" by the > spec (i.e. behavior is undefined if you do so). > The exact phrase is: "These and the GPR registers mapped into SPR space should only be used for debugging purposes by an external debugger. Applications should use the l.jal instruction to obtain the current program counter and arithmethic instructions to obtain GPR register values." Little else is said about the NPC SPR in the rest of the manual. And it's not clear what's meant by "external debugger". And I'm not sure why a paragraph about GPR access is included in the section about NPC, but there you have it. A similar problem to this can happen if the 2 least significant bits of EPCR are writable, and a misaligned PC is written to it, after which l.rfe is executed. I suppose it might be possible for a buggy OS to attempt to write a bad PC to EPCR in a context switching code... which might be an argument for *not* fixing those bits, because that way the OS can be notified of the bad PC using an exception, instead of just silently failing. OTOH, maybe it's better to not try to save buggy OS developers from their own bad code :) And since I've mentioned GPRs: section 6.4.3 on page 257 mentions accessing other contexts' registers using mfspr/mtspr. I would assume this is by using the GPR0-511 SPR addresses, but it's not clear how. (I'm not implementing fast contexts, a lot of the details in the manual are unclear or missing. This is just incidental.) -Pete
_______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
