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 > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev
_______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
