nathan binkert wrote: >> From a quick read it sounds like option 2 would be better, cleaner, >> and more extensible. In reality other than Alpha all ISAs have some >> microcoded instructions. I don't see a reason not to deal with >> microops as first class operations. >> > > I read all of both of your e-mails, and I agree with Ali on making the > microcode rom a first class citizen. Many ISAs will have microcode, > and Alpha just won't use it (though one could if they wanted to write > special instructions to do magic things.) Also, I'd say let's get > things right first, then worry about how to cache things properly. If > we do the full expansion of microops into StaticInst objects (which > sounds like the right plan to me), then we can store them in a decode > cache based on PC, and just encode the environment as a tag that is > only checked to confirm that you got the correct static inst. If the > tag doesn't match, then you replace the StaticInst in the cache for > that PC. I'd bet that in the vast majority of cases, a particular > microop at a particular PC is only ever seen in one environment, so it > would be rare for the cache to hit the PC and miss the environment. > > Were there any other questions that I should have answered? Steve > have any opinions? > > Nate > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev > I think your right between those two options. Right now, the microops are cached as part of the macroop they're from. The macroop is cached as the first level instruction from the decoder, and it statically instantiates the microops which get stored away with it. I also agree that, most of the time, or at least for some period of time, the environment for a microop will be -similar-, but not necessarily the same. Some things which could change are the several register indices of the original macroop in the usual case (not interrupts or faults at fetch).
Since I think that's mostly the direction we're going, now we need to figure out how the microops switch between decode modes, or really just switch to the ROM since switching back doesn't quite make sense (for x86 at least), what the functions in the threadcontext will be like, and how all that will be tracked and restored on mispredicts, etc. The microops, which are derived from StaticInsts, could get a new flag which says that after their execution, the decoder should switch to ROM mode. I think generally if you ever switch to a new macroop or restart the one you're on, you should revert to combinational mode to restart that instruction. One tricky aspect is if you mispredict on a microbranch. In that case, the ROMness should revert to the point of the mispredict so the microop comes from the right place. Gabe _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
