On Tue, 8 Jan 2013, Richard Sandiford wrote: > >> > I disabled 64 bit FPU instructions by "-msoft-float". This works, but > >> > using "-msingle-float" fails. This would be the better > >> > configuration. There are still 64 bit FPU instructions used (e.g. "dmfc1 > >> > $2,$f0" when using "long double" multiplication). So "-msingle-float" > >> > doesn't seem to work on generic mips64-linux-gnu. > >> > >> Right. That combination hasn't really been defined. What happens > >> for plain doubles? Do you pass those in FPRs or GPRs? > > > > IIUC the R5900 has an FPU that is functionally the same as that of the > > R4640/R4650. If that is the case, then there is no way to pass doubles in > > FPRs -- there is no room to store the upper halves. > > My point was that you could pass them in consecutive FPRs, like n32 does > for long double. There's no architectural support for long double either, > but the decision was still to pass them in FPRs rather than GPRs.
You mean using a pair of FPRs (e.g. $f0/$f2) as a sum of two values of different exponents for extra precision? That would make sense, but would not match the way the double type has been defined in the ISO C standard for IEEE-754 targets -- please note that contrariwise the standard provides more freedom as to how the long double type can be implemented on IEEE-754 targets. Otherwise it would make no sense IMO, the contents would have to be moved back to GPRs for any use anyway. > I'm not saying that that's a sensible precendent to copy. I was just > using it as one example of why an ABI has to be defined. Not necessarily, the double type may simply be banned or alias to the single type. Especially the latter -- such an arrangement is allowed by ISO C as long as the target does not claim IEEE-754 compliance (we'd have a problem with the Java frontend though) and I think such a compilation mode might be permitted as long as it is useful to someone. Maciej
