Re: Support for MIPS r5900

["Maciej W. Rozycki" <macro at codesourcery dot com>]

Hi Jürgen,

> >  Now if that failed for you, then it's a plain bug in GAS that should be 
> > fixed.  Can you therefore check whether a piece like:
> > 
> > 	.set	mips2
> > 	ll	$2, ($3)
> > 
> > assembles correctly with -march=r5900?
> 
> This seems to work. I didn't know that this would work. I thought it 
> would never be possible to generate ll and sc.

 Excellent, I hoped that it would work as we've been using these overrides 
for years, except that usually they are used to tweak the ISA selected 
rather than a specific CPU (with -march= you can request either an ISA or 
a CPU).  Your case is the first I've personally encountered where the CPU 
selected needs an override, so I'm glad that it just works.

> >  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?

> > > There are even more problems when running unchanged code from official 
> > > Fedora 12 on PS2, because of some different opcode encoding. The users 
> > > of my PS2 Linux 2.6 complain about low speed, because many instructions 
> > > are emulated. I need some fast implementation, even if the size of the 
> > > floating point data types is smaller. So 32 bit FPU must be default for 
> > > r5900.
> > 
> >  That sounds weird -- why would anyone want to use a non-standard encoding
> > for any instructions?  The base MIPS III 64-bit ISA was set as far back as
> > in 1991.  Is R5900 documentation publicly available BTW?
> 
> The documentation for r5900 is available on the first DVD of Sony's 
> Linux Toolkit and in the SDK for the PS2 which is only available for 
> people which I would call "verified Sony customers".

 OK, I see, so not really public, sigh...

> The TX79 core is similar to the r5900:
> http://www.lukasz.dk/files/tx79architecture.pdf
> But the TX79 has a 64 Bit FPU, so there are no real problems with opcode 
> encoding. This document also says that mips isa III is supported, but 
> not ll,sc,lld,scd,dmult and ddiv. In binutils/opcodes/mips-opc.c you can 
> see the different opcode encoding for c.lt.s and trunc.w.s, the missing 
> c.olt.s and cvt.w.s instructions. These are caused by the FPU. This is 
> no problem on the TX79.

 Oh well, missing instructions are not that much of a problem, they can 
always be emulated.  Instruction words that implement operation different 
to one expected are a show-stopper though.

 I see that the encodings supposed to implement C.OLT.S and C.OLE.S are 
interpreted as C.LT.S and C.LE.S, respectively.  However the former
instructions differ from the latters only in how quiet NaNs are treated.  
Given that, as you say, the processor does not support NaNs anyway, this 
may well be considered correct operation.  You may still need to emulate 
the other encoding though.

 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.

> For Fedora 12 I need to disable the FPU and emulate everything.

 Well, given the lack of full IEEE-754 support you'll always have to do 
that for generic MIPS code.  The kernel could interpret E_MIPS_MACH_5900 
set in the ELF file header flags though and enable the FPU selectively for 
compatible binaries.  Such binaries might produce computational results 
different to expected of course.  You'd have to enforce object-file 
compatibility though and make sure R5900 binaries do not run with the FPU 
enabled on other hardware too.

 That might be an interesting project if you'd like to dive into it.

> One of the biggest problem is that most Linux programs use the rdhwr 
> instruction (0x7c03e83b). I don't know any MIPS CPU which supports this 
> instruction.

 Oh, pretty much all modern MIPS processors do -- this instruction has 
been mandatory since the introduction of the MIPS32r2 and MIPS64r2 ISA 
level.  The UserLocal CP0 register accessible with RDHWR <rt>, $29 is 
however optional, so the instruction may still trap on some processors 
that otherwise support it, but there are such that do not, e.g. the 74K 
family processors.

> This has the same encoding as the "sq v1,-6085(zero)" 
> instruction on the r5900. Luckily this always leads to an alignment 
> exception which is handled correctly by my Linux kernel to emulate 
> rdhwr.

 Good.

> 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.

  Maciej