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
