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
