From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19552 invoked by alias); 19 Jan 2013 10:53:51 -0000 Received: (qmail 19433 invoked by uid 22791); 19 Jan 2013 10:53:49 -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-wi0-f177.google.com (HELO mail-wi0-f177.google.com) (209.85.212.177) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 19 Jan 2013 10:53:41 +0000 Received: by mail-wi0-f177.google.com with SMTP id hm2so3652265wib.10 for ; Sat, 19 Jan 2013 02:53:40 -0800 (PST) X-Received: by 10.194.122.98 with SMTP id lr2mr18271669wjb.55.1358592820761; Sat, 19 Jan 2013 02:53:40 -0800 (PST) Received: from localhost ([2.26.205.107]) by mx.google.com with ESMTPS id g2sm8129135wiy.0.2013.01.19.02.53.37 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sat, 19 Jan 2013 02:53:39 -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> <20130108223433.27430@gmx.net> <20130113141555.89760@gmx.net> <20130117222059.231610@gmx.net> Date: Sat, 19 Jan 2013 10:53:00 -0000 In-Reply-To: (Maciej W. Rozycki's message of "Thu, 17 Jan 2013 23:22:36 +0000") Message-ID: <8738xxmok7.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/msg00997.txt.bz2 "Maciej W. Rozycki" writes: >> 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. Yeah, if I recall correctly. We already support what I think is the same format for SPU (spu_single_format), which I suppose makes sense given its heritage. Hopefully the format itself won't need much work in GCC. Richard