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
