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. 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? 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, On Tue, Jul 30, 2013 at 11:43 PM, Steve Reinhardt <[email protected]> wrote: > In the process of adding support for a fourth class of registers (to > handle condition codes more explicitly in x86), I wound up wading through a > bunch of confusing register-handling code. In the process of trying to > figure out what was going on, I figured I would write up some > documentation, in part so that you all could look at what I think I figured > out and tell me if I got it right. (Korey had done a write-up earlier on > register indexing, but it wasn't totally comprehensive, so I decided to > start over.) > > The new page is here: http://gem5.org/Register_Indexing > > Please take a look and provide some feedback (or just edit the page > directly), particularly if you see anything there that's not accurate. > > Thanks, > > Steve > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
