> I'm pretty sure that is the appropriate fix. Full coverage of the > shadow-sets in regression testing wasnt available previously so like I > said before this is a case of implementing every instruction on the > MIPS32 ISA specification for possible future cases then "this code > works and now it's broken". Can you add comments to appropriate places to let people know that this is the case?
> It's not odd, it's just how the MIPS32 ISA is defined. If you would > like to read/write from a shadow set that's not the current set than > you must use these instructions. Except if you read them, they don't seem to do that. They still do stange multiplying by curShadowSet. Given the code in decoder.isa, > Nope, I'm not agreeing to that. So okay, maybe I should just drum up a > patch then .... :). The Number of Registers in the IntRegFile is the > number of architectural registers + HI/LO registers + DSP registers... > Those need to be replicated per shadow set. If you just say > NumIntArchRegs * ShadowRegSets you mess up the mapping. That should > still be intReg < NumIntRegs. >From isa_traits.hh: > const int NumIntRegs = NumIntArchRegs*NumShadowRegSets + NumIntSpecialRegs; > //HI & LO Regs >From int_regfile.hh: > IntReg regs[NumIntRegs]; Something is fishy with either the code or what you said. > The rest of your comments have some merit but like I said before it's > not like this shadow set code was ever *working* as much as it was > just coexisting in the code. So what we are doing here is trying to > fix something that has no test case in the 1st place. Ok, then we should get something that approximates correct add a good comment describing what's going on and move on. > What I can do is fix it and make it consistent with the rest of M5 and > the MIPS32 ISA and then email Jaidev to see if there are any updates > to the shadow set code. I thought this was a gcc 4.3 warning problem > but obviously not. I thought we had warnings in the compiles > previously but I guess the current goal for "stable" is "warning-free" > code? Yes, we want warning-free code, but we want that because the real goal is that we want the code in the tree to be as correct as possible. When we release a stable branch, we want to fix as many known bugs as possible. > In terms of there regression tests, its really not something they can > handover in terms of "here's the code". Needless to say, I cant go > into exactly what they have but it's not a list of files that you can > cross-compile to any architecture rather a large test suite that > exhaustively tests every instruction ... This is not something that MIPS is interested in releasing? If not, then I agree that compiling some of the other existing regressions (like SPEC) to run MIPS would be excellent. Can you do that? It would help us keep MIPS up and running. Nathan _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
