Steve Reinhardt wrote:
> 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?)
Yes. In the SPARC isa description those correspond to Rd_prev and
Rd_next which are only used in save and restore.
>
> - You seem to be implicitly assuming that Inst is the space for
> integer registers (since in some cases you mention FP regs
> separately), correct?
Yes. The example that I used was for the SPARC integer registers.
>
> - 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.
Yes. The peek() mappings are actually already higher than that in the
operands defined in the ISA description. The layout of Peeked has Inst,
the microcode registers, Peek- and Peek+. The microcode registers
include the index register used for the block loads and stores and the
pseudo integer registers transplanted from the MiscRegs. Some of the
relevant lines from operands.isa are below.
# The Rd from the previous window
'Rd_prev': ('IntReg', 'udw', 'RD + NumIntArchRegs +
NumMicroIntRegs', 'IsInteger', 2),
# The Rd from the next window
'Rd_next': ('IntReg', 'udw', 'RD + 2 * NumIntArchRegs +
NumMicroIntRegs', 'IsInteger', 3),
# A microcode register. Right now, this is the only one.
'uReg0': ('IntReg', 'udw', 'NumIntArchRegs', 'IsInteger', 8),
# Control registers
# 'Y': ('ControlReg', 'udw', 'MISCREG_Y', None, 40),
# 'Ccr': ('ControlReg', 'udw', 'MISCREG_CCR', None, 41),
'Y': ('IntReg', 'udw', 'NumIntArchRegs + 1', None, 40),
'Ccr': ('IntReg', 'udw', 'NumIntArchRegs + 2', None, 41),
The peek() transform needs to be applied at this level because the
instruction is really the only thing that knows what an index means.
The flatten() transform would the the primary job of that indexing
object, so once it pushed a result out the back, that would be the
authoritative register index for the rest of the CPU. The interface for
thread contexts, etc would be using the Peeked space, but because Inst
is passed through unmodified and nothing should really need anything
else, that should get you the effect that you want without having to put
that anywhere else.
>
> - It seems clear that the ISA indexing objects would have to be per
> thread; how would it relate to the current ThreadState class?
I'm not entirely familiar with that class, but I suppose it could go
inside it. I think you're right that it would need to be per thread.
>
> - How does the ISA indexing object handle speculation?
There are two aspects to that. There's speculation on the registers
within a fixed version of flatten(), and then there's speculation which
actually changes the mapping. In the former case you can speculate all
you want since by definition of this case transforming an index doesn't
have any side effects. For the later we sort of punt and say that, for
instance, if you're changing the CWP, you're going to need to delay or
squash any translations that may have happened with the old mappings.
Fortunately this only happens when you do a save/restore, etc, or if you
change privilege/global levels which is not -too- often. We could
provide some mechanism to speculatively update the mapping state early
like how fixed branches might redirect fetch early, but that starts to
be a detail of the CPU. This part probably could use some fleshing out.
>
> - Would we need a separate per-core object for core-wide ISA-specific
> state? I'm guessing we might.
We might. There's no such thing right now that jumps to mind. I remember
there being some ambiguity with SPARC where some state might have been
for all threads in a core. I think we just hope that doesn't get touched
which I think has been true. Ali might remember more what this was
about, but it may have had to do with TLBs and error reporting.
>
> 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.
That's fine since that's largely orthogonal to the other stuff. If we
were to push that down into the CPU, though, we'd have to move to two a
dimensional index in the instruction object since it has one dimensional
index arrays for sources and for destinations at present. Any time an
index goes from a space specific code path like readIntReg to a single
generic variable merge() would come into play.
>
> 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
>
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
