On Wed, 31 Jul 2013, Steve Reinhardt wrote:
OK, if no one else is going to point out the errors in my writeup, I guess
I'll have to do it myself.
My misconception was that the offsets used to unify the register index
spaces of the various classes (FP_Base_DepTag and Ctrl_Base_DepTag) were
the same for both flattened and unflattened registers. The thing that
confused me though was the code in this changeset:
http://repo.gem5.org/gem5/rev/bf5377d8f5c1
For example, we have:
flat_src_reg = src_reg - TheISA::FP_Base_DepTag + TheISA::NumIntRegs;
In my mental model, FP_Base_DepTag would always be equal to NumIntRegs, so
this didn't make any sense. So I went back an printed out the Num*Regs and
*_DepTag values for the various ISAs. I'm not sure how well this table will
come out, but here goes:
NumIntRegs FP_Base_DepTag NumFloatRegs NumIntRegs+
NumFloatRegs Ctrl_Base_DepTag ALPHA 40 40 32 72 72 ARM 42 1344 72 114 1416
MIPS 41 41 37 78 78 POWER 41 41 32 73 73 SPARC 169 105 64 233 169 X86 43
128 48 91 184
I appended the raw data in CSV format at the end in case the table doesn't
come out.
The format below is certainly better.
So in my model the first two columns and last two columns should be equal,
which is true for Alpha, MIPS, and Power, but not for the others.
Interestingly, ARM and x86 have DepTag values greater than the
corresponding Num*Regs values, while in SPARC it's the other way around.
The purpose of ARM's extremely large FP_Base_DepTag is unclear; here's the
code from arc/arch/arm/registers.hh:
// These help enumerate all the registers for dependence tracking.
const int FP_Base_DepTag = NumIntRegs * (MODE_MAXMODE + 1);
This seems like it's being set to a gratuitously large value, since
the ARM register modes don't each have a complete unique copy of the
integer registers (in fact there are only 42 unique registers, as
NumIntRegs indicates).
Actually the x86 code is more explicit about being gratuitously large:
//There are 16 microcode registers at the moment. This is an
//unusually large constant to make sure there isn't overflow.
FP_Base_DepTag = 128,
It seems particularly confusing to me that at some points in time the
offset for FP regs is FP_Base_DepTag, while at other points in time it's
NumIntRegs (and similarly Ctrl_Base_DepTag and NumIntRegs+NumFloatRegs).
Does anyone have any insight on why this is necessary?
Can point out the code? I looked through o3/cpu.cc and o3/rename_impl.hh.
Both seemed fine to me.
Meanwhile I think I'll change FP_Base_DepTag to be equal to NumIntRegs in
those architectures where it's not and see if the regressions pass...
Steve
(CSV data below)
ALPHA,40, 40, 32, 72, 72, 79,
ARM,42, 1344, 72, 114, 1416, 160,
MIPS,41, 41, 37, 78, 78, 259,
POWER,41, 41, 32, 73, 73, 0,
SPARC,169, 105, 64, 233, 169, 52,
X86,43, 128, 48, 91, 184, 204,
I suspect x86 regressions would fail. In operands.isa we explicitly set
the index for each register.
I agree that the SPARC value of FP_Base_DepTag is likely to be incorrect.
Are there SPARC regressions that have floating point code?
I am fine with renaming FP_Base_DepTag and Ctrl_Base_DepTag.
Thanks for the documentation!
Nilay
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
