I don't think you really need to be able to "cancel" those events if every distinct hardware-event was simulated. In case of a mispredicted instruction the immediately following events don't necessarily need to commit any lasting cpu state changes just like in a real out of order cpu. So I'm guessing the primary reasons why you allow de- and reallocation are efficiency and code simplicity.
nathan binkert wrote: >> I was wondering why there are re- and descheduling methods. It seems to >> me that they are a sort of error correcting mechanism for cases where >> the occurrence of an event is not yet determined. However I can't think >> of any reason why you would want to schedule an event if you're no >> completely sure when or even if it will occur. >> > > It happens all the time. Basically you plan for something to happen > and then something else comes along and cancels that action. For > example, in an out of order CPU, you'll speculatively issue an > instruction and then another instruction comes back and tells you that > your branch prediction was wrong, so you cancel that instruction. Or > you've got a timer that is supposed to expire and cause an interrupt > unless activity occurs, so you create the event, but the activity does > occur and that causes the timer to reset. > > Just look through the code, there are several examples. Now, we do > have two choices for canceling an event. Squashing and descheduling. > Squashing marks an event as dead, but leaves it in the event queue. > When the event is to be processed, the squashed flag is checked and > the event is just skipped. That works for dynamically created events. > For the timer expire type event, usually you'd statically allocate > that kind of event and since you need to use the static event again, > you need to deschedule and reschedule it. > > Nate > _______________________________________________ > 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
