On Wed, Mar 5, 2014 at 1:38 AM, Stefan Kristiansson < [email protected]> wrote:
> 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". > > The issue I'm having is that there isn't a PC associated with some bus errors. For instance suppose a load instruction misses the cache, and results in a line fill operation. Suppose the cache supports forwarding data directly from the bus to the pipeline on a load miss, and does so, allowing the load instruction to complete. The fill resumes, and a bus error occurs while filling one of the other words in the cache block. But the bus error cannot be tied to any particular PC or instruction. (My solution was just to cancel the load fill but otherwise ignore the error, but I really would have liked to report the error back to software.) Also, if the lower level memory system had some kind of parity checking, a bus error might occur intermittently (e.g. cosmic rays) and the OS want to try to recover from them somehow, e.g. by retrieving a known good copy of the data from other storage and overwriting the failed memory locations. This is the primary reason I think bus errors should be made as recoverable as possible. > 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. > > Yeah, I suppose that's a solution. For the load error situation I just described, I suppose I could hang on to the PC until the fill completes, and pass it back on an error. I don't find it ideal, though. Just treating bus errors the same as any other interrupt would be better IMO, because there might be situations in which you want to try to recover from them (as difficult as that can be to pull off). -Pete
_______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
