> So, I was thinking about this, and generally speaking I don't think > waiting for things to drain instead of squashing everything and taking > the interrupt immediately is going to work for x86. In an OS, you might > see a sequence of instructions like "sti; cli;". What that does is turn > on interrupts and then immediately turn them back off. It's used to > provide a single spot for interrupts to happen, for instance if you're > in a long loop where the work it's doing in an iteration isn't > interruptable but it can take interrupts between iterations. The "sti" > will happen, but before the interrupt can be taken, the "cli" will also > happen and prevent it. >
In this case shouldn't the sti instruction cause some form of serialization in the pipeline and make the cli wait in fetch until it completes? Otherwise both could go down the pipe and commit together, never allowing interrupts to happen. But again, I'm not entirely clear how the ISA should work in respect to this type of instruction. > I don't think you really save much by having things drain either. Sure, > you don't throw away those instructions, but you have to wait for them > before you trigger the interrupt. The other way, you trigger the > interrupt immediately and then wait for it to get through the pipe. It > doesn't make much of a difference. > > In effect the pipeline already does this, commit is acknowledging the interrupt immediately but is waiting for the pipeline to finish up its current work that has to be completed before redirecting fetch and changing execution modes. To solve the issue you are seeing with the x86 ROM, you would have to add a signal from fetch to commit that would tell commit when fetch has actually decided to stall and be redirected to the interrupt handler. Maybe by doing this via an extra time buffer. Geoff _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
