Semantically, I would say that a checkpoint or switch_cpus doesn't really "happen" until the drain completes. Thus if the user initiates one of these operations, but we run into some fatal exit condition before the drain completes, there's no reason to treat that differently than if we ran into the exit condition just before the checkpoint or switch_cpus is initiated. So there's no need to try and forge ahead past the exit condition in that case. Fatal exit events could be handled via python exceptions. In fact that might clean things up in general, if we stick the simulate loop inside a try block, and use exceptions to handle all the "unexpected" exit event types.
I can see where things might get more complicated if the code exits simulation to request another checkpoint (via a pseudo-op) while you're draining for a switch_cpu or a prior checkpoint. Perhaps the right thing to do there is have a global variable that indicates that the user has requested a checkpoint or a cpu switch, and let the low-level simulate loop just set that variable and continue, and have the high-level loop check those variables. (Or if we want to avoid global variables, we could pass that state up as part of the return code... maybe we really want low-level simulate loops as in drain to return a list of non-fatal exit events that were encountered.) It seems reasonable to add an attribute or method to exit events so we can tell which ones are fatal and which ones aren't. Or we could have a method for each exit event class that returns a python exception object, and non-fatal exit events just return None. Steve _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
