Re: Support for MIPS r5900

["Jürgen Urban" <JuergenUrban at gmx dot de>]

Hello Maciej,

> > >  Please note that the issue of LLD and SCD remains open -- these 
> > > instructions are a part of the base MIPS III 64-bit ISA and therefore
> they
> > > are assumed by glibc and elsewhere to be present, and they are not 
> > > emulated by Linux.  So not only you'll have to fix up glibc to
> surround 
> > > their use with .set mips3 for the n64 and n32 ABIs (please note that
> .set 
> > > mips3 is needed for LL and SC for these ABIs as well to avoid a 
> > > miscalculation of addresses where applicable), but you'll have to add 
> > > emulation code to Linux as well.
> > 
> > I didn't see any code yet that uses lld/scd, so it doesn't seem to be a 
> > problem. I will create a patch which includes tests that will ensure 
> > that .set mips3 will work.
> 
>  Glibc uses them exactly where it uses 32-bit LL/SC, except where a 64-bit
> data type is involved.  Of course that also requires a 64-bit ABI, either 
> n64 or n32, as these are 64-bit instructions -- from what you wrote thus 
> far I've gathered, perhaps incorrectly, that you've been using either or 
> both too, in addition to o32 -- is my understanding correct?

I used o32 and n32 for Linux programs and with the OS of the PS2. I tried to use o64 for the Linux kernel, but I've got problems with the 64 bit TLBs and that the type "long" is used for pointers, so I decided to use the o32 kernel which was patched to support n32 user space. I never tried n64. I was not able to find an option to enable n64 in the gcc 4.3 (I mean more than -mabi=n64; i.e. multilib).

>  How are unsupported floating-point data treated, BTW -- what results does
> the processor produce for floating-point encodings that would normally be 
> interpreted as not-a-number, an infinity or a denormalised number?  Are 
> they treated numerically, beyond the range IEEE-754 single provides?  You 
> say that the Invalid Operation exception is not raised, so they cannot be 
> trapped and emulated.

The manual says that the traps can be emulated by a conditional trap instructions. I saw such code before, but I can't remember if this was x86, ARM, mipsel or r5900.
I tested the calculation with the type "float".
ABI o32 with -mhard-float and -msingle-float produces the following results:
1.000000 (0x3f800000) / 0.000000 (0x00000000) = nan (0x7fffffff)
0.000000 (0x00000000) / 0.000000 (0x00000000) = nan (0x7fffffff)
0.000000 (0x00000000) / nan (0x7fc00000) = 0.000000 (0x00000000)
1.000000 (0x3f800000) + 1.000000 (0x3f800000) = 2.000000 (0x40000000)
1.000000 (0x3f800000) + inf (0x7f800000) = inf (0x7f800000)
inf (0x7f800000) + inf (0x7f800000) = nan (0x7fffffff)
inf (0x7f800000) + -inf (0xff800000) = 0.000000 (0x00000000)
nan (0x7fc00000) + nan (0x7fc00000) = nan (0x7fffffff)
nan (0x7fc00000) + nan (0xffc00000) = 0.000000 (0x00000000)

The r5900 manual calls the result of 0/0 Fmax. So 0x7fffffff seems to be Fmax.

ABI n32 with -msoft-float and -mdouble-float produces the following results (this should be correct):
1.000000 (0x3f800000) / 0.000000 (0x00000000) = inf (0x7f800000)
0.000000 (0x00000000) / 0.000000 (0x00000000) = nan (0x7f8fffff)
0.000000 (0x00000000) / nan (0x7fc00000) = nan (0x7fcfffff)
1.000000 (0x3f800000) + 1.000000 (0x3f800000) = 2.000000 (0x40000000)
1.000000 (0x3f800000) + inf (0x7f800000) = inf (0x7f800000)
inf (0x7f800000) + inf (0x7f800000) = inf (0x7f800000)
inf (0x7f800000) + -inf (0xff800000) = nan (0x7f8fffff)
nan (0x7fc00000) + nan (0x7fc00000) = nan (0x7fcfffff)
nan (0x7fc00000) + nan (0xffc00000) = nan (0x7fcfffff)

Just for comparison: x86_64, Intel(R) Core(TM) i7-2600 CPU
1.000000 (0x3f800000) / 0.000000 (0x00000000) = inf (0x7f800000)
0.000000 (0x00000000) / 0.000000 (0x00000000) = -nan (0xffc00000)
0.000000 (0x00000000) / nan (0x7fc00000) = nan (0x7fc00000)
1.000000 (0x3f800000) + 1.000000 (0x3f800000) = 2.000000 (0x40000000)
1.000000 (0x3f800000) + inf (0x7f800000) = inf (0x7f800000)
inf (0x7f800000) + inf (0x7f800000) = inf (0x7f800000)
inf (0x7f800000) + -inf (0xff800000) = -nan (0xffc00000)
nan (0x7fc00000) + nan (0x7fc00000) = nan (0x7fc00000)
nan (0x7fc00000) + -nan (0xffc00000) = -nan (0xffc00000)

> > Here is some information from the EE core user's manual regarding FPU:
> > This unit is not IEEE 754 compatible.
> > Supports single-precision format as defined in the IEEE 754
> specification.
> > Plus/Minus "0" in line with IEEE 754 specification are supported.
> > NaNs and plus/minus infinities are not supported.
> > No hardware exception mechanism to affect instruction execution.
> > 
> > The FPU only supports "Rounding towards 0".
> > ... the results may differ from the IEEE 754 Rounding to 0. This 
> > difference is usually restricted to the least significant bit only.
> > 
> > NaN, +inf, -inf and denormalized numbers are not supported
> > The FPU does not use the Guard, Round and Sticky bits during
> computations.
> > Invalid Operation exceptions due to NaN, +/-inf and Inexact exceptions 
> > are not supported.
> > 
> > Operations with different results:
> > - 0/0
> > - Sqrt (negative number)
> > - Division by zero
> > - Exponent overflow
> > - Exponent underflow
> > - Conversion of Floating-point to Integer Overflow
> 
>  OK, I guess you could still make it a supported processing unit with GCC,
> however I can't speak for GCC maintainers as to whether they would be 
> willing to accept such support for inclusion.  Both ISO C and GCC do 
> permit non-IEEE-754 floating point arithmetic (cf. VAX, that does not 
> support qNaNs, infinities or denormals; sNaNs in a sense are supported).  
> You'd probably have to bail out on sources referring to unsupported 
> features, e.g. __builtin_inf; I reckon the VAX port does that.

I am thinking on using the MIPS soft float ABI. This means everything is passed in GPRs. Then I plan to implement the libgcc softfloat functions in an optimized way using the FPU when possible.

Best regards
JÃrgen