Changing the subject line to reflect what we're actually talking about... Thanks for the writeup, Gabe. I like your diagrams, Just a couple of clarifications:
- Are Peek- and Peek+ only used for those expressions whose sources are in one window and destinations are in another? (Like save and restore, IIRC; anything else?) - You seem to be implicitly assuming that Inst is the space for integer registers (since in some cases you mention FP regs separately), correct? - If we push the peek() and flatten() mappings into an "ISA register indexing object", then in fact nothing outside that object will even know these mappings exist, correct? That would be nice. - It seems clear that the ISA indexing objects would have to be per thread; how would it relate to the current ThreadState class? - How does the ISA indexing object handle speculation? - Would we need a separate per-core object for core-wide ISA-specific state? I'm guessing we might. The idea of the merge() step (mapping *all* registers to a single integer namespace) was actually inherited from SimpleScalar; my guess is that the only thing that might really get complicated if we abandon that is register dependency handling in out-of-order models (and maybe inorder too?). Before we take the step of getting rid of that we may want to look at how we'd do those things otherwise. Or perhaps the answer is that CPU models that want to incorporate a merge() mapping are free to do so, but they must do it inside the model and we won't assume it for any external interfaces. I have some comments on Korey's email too but I'll send those out separately. Steve
_______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
