On Wed, Mar 5, 2014 at 7:08 AM, Peter Gavin <[email protected]> wrote: > So, I've been looking at the way bus errors are handled, and the > specification says that the EPC is written with the address of instruction > that caused the exception. Since bus errors are asynchronous and may occur > long after the relevant instruction (if any) has committed, shouldn't this > wording be changed? >
I understand your standpoint here; but, bus error exceptions are really "only" good for debugging, you can't really recover from them. So, the information held in EPC is an indicator of the place of where the offending access happened. I'm more interested in this information than what the CPU happens to be doing at the moment, even if that would be the more correct "return PC". I had the exact same head-scratcher moment when I added the store-buffer to mor1kx cappuccino, since that allows the pipeline to move forward while stores are being issued. To get around that, I save the PC of each store in the store buffer. > Also, since bus errors normally occur well after address translation is > complete (and the virtual address has been discarded), shouldn't EEAR be > written with the physical address (instead of virtual, as is specified)? I > don't know what the existing implementations do about this one. > I agree, and from a debugging sense of view, I think that makes more sense too. Earlier implementations have been doing load/stores in a "blocking" fashion, i.e. the load/store have been blocking any other operations. Looking again at my store-buffer case, I see that the EEAR I present in case of a store-buffer bus-error is not at all coherent with the current store operation. Stefan _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
