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
