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]> 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]>: > > > 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] 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]>: > > > > > > > > >> 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]> > > 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] > > >>>> 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 > > > > > > > _______________________________________________ > > 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 >
_______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
