From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24972 invoked by alias); 8 Jan 2013 18:25:44 -0000 Received: (qmail 24954 invoked by uid 22791); 8 Jan 2013 18:25:43 -0000 X-SWARE-Spam-Status: No, hits=-3.6 required=5.0 tests=AWL,BAYES_00,DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,FREEMAIL_FROM,KHOP_RCVD_TRUST,NML_ADSP_CUSTOM_MED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-wg0-f44.google.com (HELO mail-wg0-f44.google.com) (74.125.82.44) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 08 Jan 2013 18:25:36 +0000 Received: by mail-wg0-f44.google.com with SMTP id dr12so573608wgb.23 for ; Tue, 08 Jan 2013 10:25:35 -0800 (PST) X-Received: by 10.180.33.44 with SMTP id o12mr16617072wii.28.1357669535483; Tue, 08 Jan 2013 10:25:35 -0800 (PST) Received: from localhost ([2.26.203.77]) by mx.google.com with ESMTPS id bd6sm160613wib.10.2013.01.08.10.25.32 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 08 Jan 2013 10:25:33 -0800 (PST) From: Richard Sandiford To: "Maciej W. Rozycki" Mail-Followup-To: "Maciej W. Rozycki" , =?utf-8?Q?J=C3=BCrgen?= Urban , , rdsandiford@googlemail.com Cc: =?utf-8?Q?J=C3=BCrgen?= Urban , Subject: Re: Support for MIPS r5900 References: <20130106225645.190700@gmx.net> <87y5g43bkf.fsf@talisman.default> <87ip782kxl.fsf@talisman.default> Date: Tue, 08 Jan 2013 18:25:00 -0000 In-Reply-To: (Maciej W. Rozycki's message of "Tue, 8 Jan 2013 17:24:02 +0000") Message-ID: <87ehhv352c.fsf@talisman.default> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain 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/msg00434.txt.bz2 "Maciej W. Rozycki" writes: > On Tue, 8 Jan 2013, Richard Sandiford wrote: >> >> > I disabled 64 bit FPU instructions by "-msoft-float". This works, but >> >> > using "-msingle-float" fails. This would be the better >> >> > configuration. There are still 64 bit FPU instructions used (e.g. "dmfc1 >> >> > $2,$f0" when using "long double" multiplication). So "-msingle-float" >> >> > doesn't seem to work on generic mips64-linux-gnu. >> >> >> >> Right. That combination hasn't really been defined. What happens >> >> for plain doubles? Do you pass those in FPRs or GPRs? >> > >> > IIUC the R5900 has an FPU that is functionally the same as that of the >> > R4640/R4650. If that is the case, then there is no way to pass doubles in >> > FPRs -- there is no room to store the upper halves. >> >> My point was that you could pass them in consecutive FPRs, like n32 does >> for long double. There's no architectural support for long double either, >> but the decision was still to pass them in FPRs rather than GPRs. > > You mean using a pair of FPRs (e.g. $f0/$f2) as a sum of two values of > different exponents for extra precision? That would make sense, but would > not match the way the double type has been defined in the ISO C standard > for IEEE-754 targets -- please note that contrariwise the standard > provides more freedom as to how the long double type can be implemented on > IEEE-754 targets. No, I mean passing the two 32-bit halves in two FPRs, like we pass the two 64-bit halves of long doubles in two FPRs. Like I say... >> I'm not saying that that's a sensible precendent to copy. I was just >> using it as one example of why an ABI has to be defined. > > Not necessarily, the double type may simply be banned or alias to the > single type. Especially the latter -- such an arrangement is allowed by > ISO C as long as the target does not claim IEEE-754 compliance (we'd have > a problem with the Java frontend though) and I think such a compilation > mode might be permitted as long as it is useful to someone. But that's the point: we have to define what the rules are. The definition includes what isn't allowed. Richard