Gabe Black wrote: > 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 >
Actually, the reading/writing code isn't sufficient for the same reason as the old system, they both represent the double with one index, effectively ignoring the fact that it overlaps two single precision registers, at least without really complicating the CPU models. The function that replaces the floating point operands in SPARC is filterDoubles in arch/sparc/isa/base.isa. You'd want to use something similar on each piece of instruction code in MIPS that might use a double register. I'll attempt to implement that soon. Gabe _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
