On Wed, 25 Apr 2012, Gabriel Michael Black wrote:
Quoting Steve Reinhardt <[email protected]>:
On Wed, Apr 25, 2012 at 11:00 AM, Gabriel Michael Black <
[email protected]> wrote:
Quoting Nilay Vaish <[email protected]>:
Two things that I want to say in response --
a. With respect to memory usage, it would go down if we do what Gabe
suggested in his review i.e. introduce members for each of the registers
instead of using an array. This would also remove the indirection. I'll
get
performance numbers from some of the regression tests to carry out a
performance comparison.
b. The aim for these set of patches is remove the RAW dependence on
condition code register in x86. Current approach is to figure out at run
time whether or not the CC register needs to be read. We require this
dynamic map to correctly read the registers. In ARM ISA description, some
thing similar has been done. At runtime, if a certain condition is true,
the CC register is reda, otherwise register 0 is read. IIRC, no
instruction
can write to reg 0 in a RISC isa. Hence, there is no RAW dependence. Can
we
do this in x86 as well? May be a register that is only visible to the
microcode.
I agree, at a high level, that keeping the existing _srcRegIdx[] array and
just dealing with the fact that it may have gaps in it seems like an
alternative that's at least worth exploring.
We could also have a special register index like -1 that just means invalid
so that we don't rely on piggybacking on some potentially ISA-specific
characteristics to make it work.
That's essentially what the index constant ZeroReg does currently.
The special handling of the zero register is actually somewhat annoying.
The CPU has to check for it and treat it specially, and, last I recall,
the
way it holds its zero value is to be rewritten with zero over and over and
over to squash any errant updates. I would like to get rid of this
mechanism if possible, so my gut reaction is not to build more on top of
it. That said, the zero register behavior isn't going away so it has to
keep working somehow anyway. That may be a viable way to avoid adding
storage to the StaticInst classes.
With Alpha, the decoder generates a no-op for any instruction whose
destination is the zero register, regardless of the opcode. In theory,
this should make rewriting the zero value every cycle unnecessary. I don't
know if some cases were missed, or if it's still needed for other ISAs, but
that's the direction I'd want to go to get rid of that aspect. We could
always just replace the overwrite with an assertion and see how far we get.
On the input side, it would seem that instructions that read the zero
register could be decoded into StaticInsts that act as if it were an
immediate zero operand.
So I'd think it's at least theoretically possible to make the current
zero-register implementation go away.
Also, PowerPC has funky semantics in which the zero register actually holds
a value, and whether you get that value or 0 depends on the opcode. I'm
not sure how that's implemented in gem5, but we can't assume that the
zero-register behavior is universal.
Steve
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
That's not necessarily feasible because you'd end up with lots of variations
of everything where one or more sources and/or one or more destinations are
replaced in some way. It's also not desirable to turn them into nops because
you may still want side effects like setting condition codes. This is how at
least the cmp instruction is implemented as microcode in x86.
A long time ago I proposed using our index flattening mechanism to flatten
dests that had magical zero properties to a dead register, and I think that
would still make sense. There would be a little bit of overhead because
sources will still read from a zero register and dests will still write to a
/dev/null register, but renaming sorts of operations would be minimal.
Gabe
Seems like the main discussion is getting side tracked. So do people think
that we should do this? The zeroth micro int register is defined to be the
ZeroReg. Does that mean if the operand is ZeroReg, it would map to 0?
Also, where are these micro int registers being used? There aren't many
places where INTREG_MICRO() is in use.
--
Nilay
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
