Gabriel Michael Black wrote: > Quoting Korey Sewell <[email protected]>: > > >>> I haven't checked too carefully, but this same problem may be >>> affecting ARM as well (since I think it uses the same paired >>> floating-point register scheme). Also, other double-precision things >>> like checking for NaNs may be broken by this change. >>> >>> >> Yea, I know I have got a few of the regressions for SPEC2K-INT on MIPS >> working, but was unable to fully get working twolf as I think that >> particular benchmark wants to use some floating point as well... >> >> As you note earlier, M5 used to handle this correctly but it was a bit >> tricky in implementation. Because the bits need to be concatenated together >> for double precision you cant keep that floating point register file as an >> array of "FloatReg" since the bits will be out of order for concatenation. >> Instead, you need to keep each register really as a "IntReg" or "uint32_t", >> then when you want to read a floating point reg you have to do some >> manipulation to read it out for the right floating type and width. So in >> concept a "FloatReg f" register file wont work correctly here. I had it all >> working before so maybe a simple peek to the old code can be used to update >> the new code if need be. >> >> Also, for MIPS since there are 32-bit and 64-bit precision, there should be >> two types available to distinguish things "FloatReg32" and "FloatReg64". >> >> -- >> - Korey >> >> > > This should work like SPARC which has the same register file set up. > Basically, you read two single floating point registers and > concatenate them into one double. There shouldn't be any additional > types or functions. I remember there was some discussion about this a > while ago, but I don't remember all the details. I think the problem > is basically that I removed the old style of doing things without > adding support for the new style. Since the regressions that were in > place worked, I incorrectly assumed it was fine. If you want to fix it > you'll want to look at what SPARC does and do something similar. The > old way was pretty broken when dealing with register dependencies. > > Gabe > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev >
Actually, since I fixed up SPARC, a new mechanism for specifying custom code for reading/writing register operands was added up for ARM. Right now SPARC uses a regular expression to replace mention of double registers with code that computes it from two single registers, and it works out. With this new mechanism, that could be moved into custom reading/writing code and be less mysterious and magical. I'll give that a shot soon (this weekend hopefully), and if it works out I'd recommend doing the same for MIPS. You can see an example of what I'm talking about in the ARM isa description's operands.isa (or similar) file. Gabe _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
