On Fri, 27 Apr 2012, Gabe Black wrote:
On 04/27/12 11:01, Nilay Vaish wrote:
On Fri, 27 Apr 2012, Gabe Black wrote:
On 04/27/12 07:02, Nilay Vaish wrote:
On Wed, 25 Apr 2012, Nilay Vaish wrote:
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
I went through some of the code. It seems that the 't*' registers used
in the microcode would map to the MicroInt registers. I think it is
possible to do a zero register. We can introduce a new register that
does the job. Or else we can reuse one of the micro int registers.
t13/t14 are not in use at all. So they can be used. But we will have
to maintain a discipline of not using these any where else.
--
Nilay
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
Don't use t13 or t14. t0 is already defined as the zero register.
Gabe
But t0 is use in lots of places. Are you fine with changing those to
t13/t14?
--
Nilay
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
No. t0 is already the zero register, and yes it's used in a lot of
places. Nothing about the registers needs to change. Every ISA in gem5
has a zero register already because Alpha has one (which is somewhat
unfortunate), and its index is specified with the ZeroReg constant.
Gabe
I thought t0 was being used as any other t* register. Thanks Gabe.
--
Nilay
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
