On Tue, Sep 23, 2008 at 8:51 PM, Gabe Black <[EMAIL PROTECTED]> wrote:
> I'm mostly concerned about handling the interrupt, not actually handling > the fault from fetching. There are sort of two dimensions to this problem. > > First is that there isn't really a good way to tell when a macroop ends > when you cause control flow external to the macroop. That is, if you > don't end it because you ran into a microop that has the right flag set. > There might even be cases where you "fault" in microcode, but really > that's an easy way to handle a special case somewhere else in microcode. > After you fix things up, you'd go back and keep operating in the same > microop. In that case, not even a fault ends the current macroop. That's > a somewhat extreme case, but it's not easy, and probably not possible, > to characterize whether you've left a macroop just by the externally > induced micro/macro/combinational vs. ROM control flow. I believe it's impossible fault on a microop in the middle of a macroop and then resume where you left off in the middle of the macroop flow. If you fault you will roll back to the state at the beginning of the macroop and then on resuming from the fault you either have to reexecute the macroop from the start or skip it entirely. So it seems like the two cases where you're in the middle of a macroop flow and you end the macroop are either (1) the final, specially marked microop of the normal flow hits retire or (2) a microop causes a fault and the whole macroop is discarded and the fault handler is invoked. Interrupts don't count because you'd never take an interrupt in the middle of a macroop. > > > The second is that if you try to create a macroop for a PC you don't > care about, a PC which you just happened to be at because it was just as > good as any other PC, that process might fail. If you get an interrupt, > for instance, you don't care what the PC is since you're only going to > work out of the ROM. The PC -is- still set to something, and as I said > earlier you can't tell whether you mean to execute inside the context of > that PC or not. If you default to trying to fetch that PC and it doesn't > work, you might get hung up at that stage, and never actually get to > executing microcode to enter the interrupt. The reason I brought up > faulting at fetch is that leaving the PC alone is the easiest, and in > that case you would have a PC which you couldn't successfully fetch from. On an interrupt you will go from the "normal" PC to the starting PC of the interrupt vector, and the "no man's land" in between should only belong to microops that only serve the purpose of bridging that gap and thus know that the PC they're looking at is not quite valid, right? > > > Also, fetching a macroop when you're not going to use it is inefficient, > and may have an impact on how accurately we model performance. That's a > secondary concern at the moment since not working will have a much > larger impact :), but it's something to think about. I'm not worried about this at all. The only time it's bad is if the fetch causes a page fault, but even then you should discard that page fault before it hits retire so it never gets processed. Steve > > > Gabe >
_______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
