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. 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. 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. Gabe Steve Reinhardt wrote: > I don't see the problem... if there was a page fault on fetch you > don't have a real macroop anyway, just the fake one we conjure up to > carry the fault to retirement. If the microcode is capable of > signaling the fault without the fake macroop then maybe for x86 we > should just get rid of the fake macroop. Or are there other > complications? > > Steve > > On Tue, Sep 23, 2008 at 5:20 PM, <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > Unfortunately there's still one missing component here. If you > switch to the ROM > and change the micropc, you may just be starting up the part of > the macroop > stored in the ROM, or you may be, for instance, trying to enter an > interrupt > handler. In the former case you want a macroop and in the later > you don't, but > it isn't clear how to differentiate between the two. > > Most of the time the problem isn't that big of a deal because you > can just > ignore the macroop, but in cases where the macroop doesn't work at > all, like on > a page fault in instruction memory, that can effectively block an > interrupt from > happening. > > One possible solution is to keep the macroop around effectively > until you know > for sure you finished a macroop, or if the thread context tells you to > artificially kick it out with some sort of function. A possible > name is > "endMacroop". > > Gabe > > Quoting Gabe Black <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>>: > > > I've considered it, and I think this is a good solution. I'm > going to > > pass the current macroop into the rom when getting microops, and > then > > when this gets to o3 at some point, keep the current macroop in the > > DynamicInst. > > > > Gabe > > > > [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> wrote: > > > I'll have to think about it more, but at first pass that > sounds pretty > > good. It > > > might also help generate better/more descriptive disassembly > which is > > something > > > I've wanted to do for a while. > > > > > > Gabe > > > > > > Quoting Steve Reinhardt <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>>: > > > > > > > > >> How about having a "current macroop" pointer in the execution > context (so > > >> there would be a single pointer for SimpleCPU, and it would > live in the > > >> DynamicInst object in O3)? > > >> > > >> On Sun, Sep 21, 2008 at 11:25 PM, Gabe Black > <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> > > wrote: > > >> > > >> > > >>> To break this into more digestible chunks, I need a way to > get important > > >>> information from the most recent macroop to the ROM so it > can tune it's > > >>> microops accordingly. > > >>> > > >>> I'd like to have two different types of regions in the ROM, > those that > > >>> are extensions of combinational macroops and need the > specifics of the > > >>> original macroop to do their job, and those that use a > predefined set of > > >>> parameters so they always work in predictable ways (and > don't require a > > >>> macroop). > > >>> > > >>> When the ROM was just an abstraction internal to the > macroops, really > > >>> just a special range of micropcs, the macroop itself could > ferry that > > >>> information along when it got microops from the ROM to give > to the > > >>> decoder. Now that the decoder gets the microops directly > from the ROM, > > >>> the information needs a new way to get to there. > > >>> > > >>> Two possibilities are that the decoder could expose the last > macroop to > > >>> the ROM so the ROM can pull out what it needs itself. The > other is that > > >>> the macroop sets up state maintained in the decoder which is > exposed to > > >>> the ROM for the same purpose. Exposing the macroop would > probably be > > >>> easier, but then it's easier to do something bad if there's > no macroop > > >>> but the ROM expects one. Liberal application of assert(ptr > != NULL) > > >>> would probably help mitigate that. > > >>> > > >>> One additional complication is if you mispredict or > otherwise need to > > >>> reset to a particular microop in the ROM. It could be hard > to figure out > > >>> if you need to get a macroop so the ROM can get the state it > needs, or > > >>> if the PC is nonsense and the ROM doesn't need the macroop. > In this > > >>> case, if the macroop is needed, fetch/decode should generate > it, and if > > >>> it causes a fault the fault should be handled. If the > macroop isn't > > >>> needed, fetch/decode shouldn't try to get it, and if they do > and a fault > > >>> happens, the fault should be ignored. I'm not sure what the > best way to > > >>> differentiate these is. One option would be to add more > state which says > > >>> whether or not the microops are stand alone and not intended > to be part > > >>> of a macroop. I feel like the decoder might be trying to > keep track of > > >>> too many things already, so some way to work that in there > without just > > >>> layering it on top would be best. > > >>> > > >>> Gabe > > >>> > > >>> Gabe Black wrote: > > >>> > > >>>> I'm getting pretty close to starting with the interrupt > entering > > >>>> microcode, but one annoying issue I'm not sure how to deal > with is > > >>>> passing an environment to the microops in the ROM. For the > interrupt > > >>>> code it's not as important because for a particular mode, > the code > > >>>> should always behave the same way, generally outside the > scope of any > > >>>> instruction. In the case of macroops being partially stored > in the ROM, > > >>>> it becomes more important since the registers used, the > various widths > > >>>> involved, etc. become more important. The ROM itself as it > stands spits > > >>>> out instructions which correspond to a particular micropc > but aren't > > >>>> otherwise specialized. If this was just x86, the > obvious/easy solution > > >>>> would be to pass the emulation environment and extended machine > > >>>> instruction being used with the current macroop through to > the ROM as > > >>>> the instructions are generated. Since it isn't, I need some > way to get > > >>>> that information, whose existence is unknown to the > decoder, out of the > > >>>> macroop, and then pass it into the ROM when a microop is > requested. Any > > >>>> ideas how that might work? I'm really trying not to turn > decode into a > > >>>> big convoluted mess so I'm trying to do this with a very > light touch. > > >>>> > > >>>> Gabe > > >>>> _______________________________________________ > > >>>> m5-dev mailing list > > >>>> [email protected] <mailto:[email protected]> > > >>>> http://m5sim.org/mailman/listinfo/m5-dev > > >>>> > > >>>> > > >>> _______________________________________________ > > >>> m5-dev mailing list > > >>> [email protected] <mailto:[email protected]> > > >>> http://m5sim.org/mailman/listinfo/m5-dev > > >>> > > >>> > > > > > > > > > > > > > > > _______________________________________________ > > > m5-dev mailing list > > > [email protected] <mailto:[email protected]> > > > http://m5sim.org/mailman/listinfo/m5-dev > > > > > > > _______________________________________________ > > m5-dev mailing list > > [email protected] <mailto:[email protected]> > > http://m5sim.org/mailman/listinfo/m5-dev > > > > > > > _______________________________________________ > m5-dev mailing list > [email protected] <mailto:[email protected]> > http://m5sim.org/mailman/listinfo/m5-dev > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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
