Quoting Nilay Vaish <[email protected]>:
On Wed, 25 Apr 2012, Ali Saidi wrote:
On April 25, 2012, 7:37 a.m., Steve Reinhardt wrote:
I believe I understand why this is necessary,
Steve Reinhardt wrote:
Oops, clicked "publish" instead of "save" by accident...
My concern is that we are adding an array to every instruction,
and a level of indirection to every register access, when the vast
majority of the time this is an identity mapping. And "vast
majority" will be 100% for many ISAs. I don't know how
significant the performance impact will be, but I'm confident that
it will not be in the right direction.
I don't have a specific proposal to avoid this, but I don't
want to see this code go in lightly without consideration of the
performance impact.
I second this concern.
- Ali
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.
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.
Gabe
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
