I don't think this optimization will work. The reason that the get and update parts were separated was because getInterupt() is supposed to be callable without changing the interrupt/system state. If memory serves the reason for this is because there are cases where you might call get a fault multiple places interrupt + itb fault + something else and the fault priority the ISA specifies is not the order which we would generate things. The two step process allows us to fix that up.
Ali On Sep 8, 2008, at 2:01 AM, Gabe Black wrote: > Since I've been poking around the Interrupts object, I've noticed > we've got a lot of functions on there, and we can probably trim that > down a bit. There are functions related to setting and clearing > interrupts which go away when those are delivered through the memory > system, although that transition will take a while and I'm not > planning > on it any time soon. Also, there are three functions related to > getting > an interrupt to process. There's check_interrupts which returns a bool > of whether or not there's an interrupt waiting, getInterrupt which > actually retrieves the interrupt, and updateIntrInfo which records the > fact that the interrupt is about to happen in the ThreadContext. > What I > think will work and be a bit more streamline is to combine > getInterrupt > and updateIntrInfo into one function called, for instance, > acceptInterrupt. This way you can check whether an interrupt is ready > whenever you want without going through the overhead of actually > generating it, and when you're ready to actually invoke it, you can do > that all in one shot. I haven't actually tried doing this so I'm not > sure there isn't some corner case it can't handle, so if Kevin or > Korey > could comment that would be helpful. Also, check_interrupts probably > should be renamed checkInterrupts to match the style of the other > function names. > > Gabe > _______________________________________________ > 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
