On Sun, Apr 22, 2012 at 10:32 PM, Gabe Black <[email protected]> wrote:
> On 04/22/12 20:42, Steve Reinhardt wrote: > > I'm jumping in partially informed, but can we just have two functions, >>> like: >>> >>> zaps = setZaps(<something>); >>> >>> and >>> >>> zaps = modifyZaps(zaps, <something>); >>> >>> and then let the isa parser do its stuff naturally? >>> >>> Steve >>> >>> >> I don't think that is possible. This code will appear in the .isa file. >> In the .isa file, we cannot decide which version to use as the CC bits to >> be written vary with the context in which the microop is used. So, we need >> a run time condition that figures out tries to evaluate if the register >> needs to be read. >> > > Sorry for being way behind on this, but I'm curious just how many > microops there are that have different impacts on the flags depending on > their context, and how many different contexts there are. I got the > impression before that there would be this huge explosion of microops if we > actually had a different ADD micro-op (for example) for each set of bits > that it could possibly write. However, looking at Appendix E of Vol 3 of > the AMD ISA manual, it looks like the set of bits written by each > macro-instruction (at least) is pretty well defined. I can believe that > it's also valuable to have an ADD micro-op that doesn't affect flags for > use in microcode sequences. But is there a 3rd version of ADD we need that > modifies some but not all the flags that the ADD macroinstruction does? > > Basically if (hypothetically exaggerating) 80% of the macro-ops can > modify five different combinations of flags depending on context, then this > complex mechanism makes sense. On the other hand, if there are a small > number of microops that need two versions (one that modifies a certain set > of flags and one that doesn't), and maybe an even smaller number that > legitimately decide which flags to look at at runtime, then this is > starting to feel like overkill. I'm sure the truth is somewhere in the > middle, but I just don't understand the code well enough to know which > extreme it's closer to... and if it's close to the former, I'd like to > understand why. > > Steve > > > Being well defined and being consistent are not the same things. I looked > through the instruction reference one instruction at a time a year or two > ago tabulating what flags they set, and it was not apparent that there were > some small number of combinations. You are welcome to repeat the process, > but I'll pass. > Are you saying that if I looked closely, I would get a different result than the table that's already provided in Appendix E of Vol. 3? > Also, we're not setting flags at the macroop level, we're setting them at > the microop level. > Yea, I understand that, and already mentioned that above. To quote: "I can believe that it's also valuable to have an ADD micro-op that doesn't affect flags for use in microcode sequences. But is there a 3rd version of ADD we need that modifies some but not all the flags that the ADD macroinstruction does?". > Besides the fact that I don't think such a small set exists, I don't want > to have to live with that small set for forever, or redo all the existing > macroops so they use the right version of the microops. > I'm not arguing for or against anything right now, I'm just trying to understand the situation a little better. So far all the design discussions have implied that there are just crazy scads of microops that could decide to read or write any arbitrary subset of flags at any time, and that seems a little suspicious to me. I can believe that there is enough diversity to make all this mechanism worthwhile, I'd just like to get more specific examples and a better handle on the scope of the problem. Steve _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
