I'll buy that. Gabe
Quoting Ali Saidi <[EMAIL PROTECTED]>: > 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 > > m5-dev@m5sim.org > > http://m5sim.org/mailman/listinfo/m5-dev > > > > _______________________________________________ > m5-dev mailing list > m5-dev@m5sim.org > http://m5sim.org/mailman/listinfo/m5-dev > _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
