This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Support for MIPS r5900
Hi JÃrgen,
> > 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).
Well, -mabi= is exactly the option that switches between the three ABIs
supported under Linux. The o64 ABI is not supported with Linux, neither
for userland programs nor for building the kernel.
The kernel can be built either for 32-bit or for 64-bit support. In the
former case the resulting binary is o32 and can only run o32 user
programs. In the latter case the kernel binary is n64 and can run n64
user programs, and can optionally be configured to run either or both o32
and n32 user programs as well.
Of course to be able to build and run user programs for the respective
ABIs you need to have the right development environment and shared
libraries installed.
For 32-bit systems it's easy as you only have one ABI to choose from.
The mips-unknown-linux-gnu and mipsel-unknown-linux-gnu targets are the
canonical configuration triplets to configure all the pieces for, starting
from binutils and GCC, for the big and the little endianness respectively.
That'll build an o32 development environment.
For 64-bit systems all the three ABIs are supported so it gets a tad more
complicated. The mips64-unknown-linux-gnu mips64el-unknown-linux-gnu
targets are the canonical configuration triplets here and that'll build
binutils and GCC that support all the three ABIs. Then the compiler
chooses among them by using different library paths -- there are multiple
of them for each of the ABIs supported, but the rule of thumb is the
actual directories where the libraries are located in is called "lib" for
the n32 ABI, "lib64" for the n64 ABI and "lib32" for the o32 ABI. You
need to take that into account and set the correct library path -- e.g.
with --libdir=\${exec_prefix}/lib64 for GNU autoconf scripts and the n64
ABI -- when building further libraries as they are not normally
automatically built for all the three ABIs. Of course you then need to
include -mabi=n64 among CFLAGS somewhere too.
> > 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.
Yeah, but then you'd have to put these explicit trap instructions
througout code somehow -- it's not like the affected floating-point
instructions are going to trap themselves as expected.
> 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.
So presumably you can get 0x7fffffff as an arithmetic result of a
calculation involving regular numbers as well, right? Say 0x7f7ffffe +
0x74000000 (using the binary-encoded notation)? That would be beyond the
IEEE-754 single range.
> > 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.
That's sounds like a good idea to me, although you'll probably still have
to sort out the issue of using the FPU for R5900 binaries, but not use it
by accident for regular MIPS binaries somehow. That could be handled by
the kernel, by enabling the FPU selectively, for example using the way I
previously outlined.
Maciej