On Fri, Feb 11, 2011 at 12:45 PM, Gabe Black <gbl...@eecs.umich.edu> wrote:
> This is for error checking in microcode. Lets say you have microcode like > this: > > // Check for flag foo to enable feature bar > and t1, t2, t3 > // If foo isn't set, skip over the microcode for bar > br afterBar > panic "Feature bar not implemented" > afterBar: > blah blah > > Or you could make that a warn if feature bar wasn't that important. I > suppose DPRINTF might sort of work, but it's not obvious how you could > generically pick a trace flag to control it with. You'd have to pick > something and hard code it, I think. > Ah, OK, this makes a lot more sense now... > Also, how do we distinguish panic from fatal in this case? I guess it's > hard to decide a priori when you get something like a machine-check error > whether that's due to a user error or an M5 bug, but I'd think we would pick > one or the other (probably assume it's a user problem, like a bad kernel or > device, and call it fatal) in which case we wouldn't need panic. > > > This isn't for reporting the sort of problem I think you're assuming it is, > though maybe I misinterpreting what you're saying. It seems to me that fatal > or panic could each be appropriate some times, although I'd like to hear > more about why you don't. > My thinking is that ISAs have very comprehensively defined behaviors, e.g., even if you give an instruction invalid inputs then there's a well-defined fault that it is supposed to return. So I can see panics or warnings for running into behavior that isn't implemented in m5, but fatal implies that the m5 user did something wrong (like specify a bogus configuration), and it's difficult to think of a way that a user could mis-specify something that would lead to an ISA-level situation (without being caught at some higher level) where it's clear that it's a user error and not something else. The one example I can come up with is if some m5 pseudo-instruction gets executed with an invalid argument value, but I'm not positive this kind of fault is the right way to handle that. Maybe it is though. Steve
_______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
