On 02/12/11 12:08, Steve Reinhardt wrote: > > 1. I like the idea of moving this out of x86, although practically > speaking I don't know that any other ISA would be able to use it right now. > I'll still move it though. This is, of course, talking about the faults > themselves and not the instruction objects. The instructions are x86 specific. > > Right, I'm just talking about the fault objects, and even though no > other ISA uses them right now this at least opens up that possibility > for the future. > > 2. Ok. I don't really see how it's better, but I don't think it's worse. > > Thanks. > > 3. Yes. X86 uses all those for it's debugging microops. They were brought > into existence so that those microops could be speculatively executed safely. > > If it's purely for debugging, then would DPRINTF be more appropriate > than warn? I still don't quite understand your usage model here.
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. > > 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. Gabe
_______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
