I'm pretty ambivalent by now myself... back when I didn't understand what you were doing and wasn't sure why you'd need warn either, then this point mattered because I thought you could get away with just doing the panic version. But I agree that if you're doing panic and two flavors of warn then it sort of makes sense to do fatal do just for completeness. So back at you, I'm fine either way too.
Steve On Sat, Feb 12, 2011 at 8:44 PM, Gabe Black <gbl...@eecs.umich.edu> wrote: > Ok, that makes sense. pseudo-instructions are a bit difference since you > generally don't want to execute those speculatively. They're usually doing > something complicated that couldn't be rolled back if you discovered you > weren't supposed to go that way. Since you aren't doing them speculatively > at all, it would be fine to have the call to fatal right in the backing > function. It would probably be reasonable to axe the fatal version of the > fault and microop and leave the other three. Do you think that's worthwhile, > though, since it's the only one and that would be a little asymmetric? I'm > ok with it either way so I'll leave it up to you. > > Gabe > > > On 02/12/11 20:16, Steve Reinhardt wrote: > > 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.orghttp://m5sim.org/mailman/listinfo/m5-dev > > > > _______________________________________________ > m5-dev mailing list > m5-dev@m5sim.org > http://m5sim.org/mailman/listinfo/m5-dev > >
_______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
