From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 308 invoked by alias); 17 Jan 2013 22:21:08 -0000 Received: (qmail 32757 invoked by uid 22791); 17 Jan 2013 22:21:07 -0000 X-SWARE-Spam-Status: No, hits=-0.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_NO X-Spam-Check-By: sourceware.org Received: from mout.gmx.net (HELO mout.gmx.net) (212.227.17.20) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 17 Jan 2013 22:21:02 +0000 Received: from mailout-de.gmx.net ([10.1.76.1]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MN7As-1TpL3k2ZNA-006d3D for ; Thu, 17 Jan 2013 23:21:00 +0100 Received: (qmail 7634 invoked by uid 0); 17 Jan 2013 22:21:00 -0000 Received: from 84.178.41.240 by www025.gmx.net with HTTP; Thu, 17 Jan 2013 23:20:59 +0100 (CET) Cc: binutils@sourceware.org, gcc-patches@gcc.gnu.org Content-Type: text/plain; charset="utf-8" Date: Thu, 17 Jan 2013 22:21:00 -0000 From: =?iso-8859-1?Q?=22J=FCrgen_Urban=22?= In-Reply-To: Message-ID: <20130117222059.231610@gmx.net> MIME-Version: 1.0 References: <20130106225645.190700@gmx.net> <87y5g43bkf.fsf@talisman.default> <20130108223433.27430@gmx.net> <20130113141555.89760@gmx.net> Subject: Re: Support for MIPS r5900 To: "Maciej W. Rozycki" Content-Transfer-Encoding: 8bit X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2013-01/txt/msg00926.txt.bz2 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