I understand that most double-precision MIPS FP operations (like add.d) are designed to work when only 32-bit FP registers are present (by using pairs FP registers). What I'm referring to are MIPS instructions that assume 64-bit FP registers (not paired 32-bit FP registers providing a double precision operand).
Take, for example, the CEIL.L.fmt instruction (where fmt can be one of S or D), the "Fixed Point Ceiling Convert to Long Fixed Point" instruction. It is marked as "64-bit FPU only" in the MIPS reference manual. The manual has this to say about this instruction in the "Restrictions" section of the instruction's description, "The result of this instruction is UNPREDICTABLE if the processor is executing in 16 FP register mode". I don't know what 16 FP register mode could mean except that the 32 32-bit FP registers are being treated as 16 paired double-precision values. There are MIPS processors with 32 64-bit FP registers and I believe that instructions like the one above are designed to work exclusively with those processors. Otherwise, the result is "UNPREDICTABLE". And since M5 only models 32 32-bit FP registers (which can be treated as either 32 single-precision values or 16 double-precision paired values), I think these "64-bit FPU only" instructions should give a warning or error if executed in m5. Note that this doesn't apply to the double-precision FP add instruction you mentioned (add.d). The MIPS manual does not restrict this instruction to 64-bit FPUs only. However, to the add.ps instruction it does seem to apply. The manual gives this warning in the "Restrictions" section for that instruction: "The result of ADD.PS is UNPREDICTABLE if the processor is executing in 16 FP registers mode." Anyway, I've only tested the patch on double-precision FP instructions that do not carry the restriction that the result is unpredictable if executing in 16 FP register mode (because I thought we only had 16 double-precision FP pairs). So, getting these instructions to work (if they ought to be) may require some additional work and testing. On Tue, Dec 29, 2009 at 6:41 AM, Gabe Black <[email protected]> wrote: > M5 does support 32 and 64 bit FP registers and operations at the same > times, but it's indirect and I can see why it's confusing. As a > hypothetical (and potentially not 100% correct) example, lets look at an > instruction that adds two 64 bit FP values into a third. The instruction > code in the ISA description might look like: > > Fd_d = Fa_d + Fb_d; > > The filterDoubles function would see that, and would munge it so that > the same thing was happening with single precision registers being put > together into doubles and taken apart again in line. It might look like > the following, assuming the DoubleSingle union in your patch. > > double Fd_d; > double Fb_d; > double Fa_d; > Fa_d = DoubleSingle(Fa_low, Fa_high).d; > Fb_d = DoubleSingle(Fb_low, Fb_high).d; > Fd_d = Fa_d + Fb_d; > Fd_low = DoubleSingle(Fd_d).s[0]; > Fd_high = DoubleSingle(Fd_d).s[1]; > > When that then gets processed by the isa parser, it will see Fa_low, > Fa_high, Fb_low, and Fb_high used as single precision source operands, > and Fd_low and Fd_high used as single precision destination operands. > The src and dest index arrays will reflact that, and each, separately > indexable unit will have its dependencies tracked correctly. In the > instruction, the right registers get merged into double precision > values, operated on as such, and then split back apart. The -storage- > for the registers is 100% single precision, and as far as the isa parser > is concerned there are no double precision operands, but from the > perspective of the isa description writer and from a functional > perspective there's both single and double precision that do what you'd > expect. > > As you can see, there's a bit of black magic going on here as far as > switching things out behind the parser's back. I discovered the > dependency problem when I had very little time to get something working, > and while this solves the problem correctly as far as I can tell it's > not as friendly as I'd like. It would be nice to have something in place > that's more obvious, like the operand writing/reading option I mentioned > before that didn't actually work out, but there isn't anything right now. > > Gabe > > Matt wrote: >> What I meant by M5 not modeling a 64 bit FPU is that M5 doesn't model >> a MIPS FPU with 64-bit wide FP registers. While MIPS32 processors >> with floating-point support have 32-bit FP registers, MIPS64 >> processors have 64-bit FP registers. The MIPS ISA (as defined in >> "MIPS32 Architecture for Programmers, Volume II: The MIPS32 >> Instruction Set") has support for both. And some instructions (like >> CEIL.L.D, CVT.PS.S, LUXC1, and many more), which look like they have >> some support in M5, are only relevant with a 64-bit FPU, which, as far >> as I can tell, M5 does not model. Or is there a way to configure M5 >> to model 64-bit floating point registers instead of 32-bit ones? >> Maybe I'm just not seeing it. >> >> It seems that all the instructions marked "64-bit FPU Only" in the >> MIPS reference manual should throw some kind of warning or error if >> they are ever executed in M5 (if it cannot be configured to support >> 64-bit wide FP registers) instead of just silently doing something >> unpredictable. >> >> On Tue, Dec 29, 2009 at 5:27 AM, Gabe Black <[email protected]> wrote: >> >>> I notice that you comment out some function calls in this patch, and >>> that's probably not the right thing to do. You wouldn't be the first, >>> but generally it's better to either fix the problem by fixing the >>> function, to get rid of the broken implementation entirely (probably too >>> drastic), add a warning and a return at the top of the function, just >>> leave it for a later patch, etc. >>> >>> What do you mean about M5 not modeling a 64 bit FPU? Do you mean that it >>> uses native FP instructions which might be x87 based and be represented >>> as 80 bits? If not, supporting 64 bit FP operations shouldn't be any >>> different than supporting 32 bit ones or integer ops. >>> >>> Gabe >>> >>> Matt wrote: >>> >>>> I followed your advice, Gabe, and fixed double-precision >>>> floating-point in MIPS by following the SPARC implementation. With the >>>> attached patch, basic double-precision stuff is fixed. There are a >>>> couple of things that are not yet fixed: >>>> 1. floating-point NaN checking. >>>> 2. instructions that assume a 64-bit FPU (like most of the Paired >>>> Single format instructions). I don't think that at this time there >>>> is a way to configure M5 to model a 64-bit FPU anyway. >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> m5-dev mailing list >>>> [email protected] >>>> http://m5sim.org/mailman/listinfo/m5-dev >>>> >>> _______________________________________________ >>> m5-dev mailing list >>> [email protected] >>> http://m5sim.org/mailman/listinfo/m5-dev >>> >>> >> >> >> >> > > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev > -- Cheers, Matt _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
