Support for MIPS r5900
Sun Jan 13 14:16:00 GMT 2013
> 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.
> 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.
> > So the FPU needs to be disabled and completely emulated by the kernel,
> > because then all FPU instructions lead to an exception. This is working
> > with Linux 2.6 on PS2.
> Naturally, as long as they got the Coprocessor Unusable exception right.
Yes, this exception is also working for instructions with undefined behavior.
> > 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".
The TX79 core is similar to the r5900:
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.
For Fedora 12 I need to disable the FPU and emulate everything.
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. 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.
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:
- Sqrt (negative number)
- Division by zero
- Exponent overflow
- Exponent underflow
- Conversion of Floating-point to Integer Overflow
More information about the Gcc-patches