From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9321 invoked by alias); 7 Jan 2013 20:44:18 -0000 Received: (qmail 9266 invoked by uid 22791); 7 Jan 2013 20:44:17 -0000 X-SWARE-Spam-Status: No, hits=-3.5 required=5.0 tests=AWL,BAYES_00,DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_SPAMHAUS_DROP,NML_ADSP_CUSTOM_MED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-wg0-f48.google.com (HELO mail-wg0-f48.google.com) (74.125.82.48) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 07 Jan 2013 20:44:09 +0000 Received: by mail-wg0-f48.google.com with SMTP id dt10so9892261wgb.3 for ; Mon, 07 Jan 2013 12:44:08 -0800 (PST) X-Received: by 10.180.107.130 with SMTP id hc2mr11237045wib.12.1357591448277; Mon, 07 Jan 2013 12:44:08 -0800 (PST) Received: from localhost ([2.26.203.77]) by mx.google.com with ESMTPS id w5sm13736243wif.11.2013.01.07.12.44.06 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 07 Jan 2013 12:44:07 -0800 (PST) From: Richard Sandiford To: Jeff Law Mail-Followup-To: Jeff Law , =?utf-8?Q?J=C3=BCrgen?= Urban , gcc-patches@gcc.gnu.org, rdsandiford@googlemail.com Cc: =?utf-8?Q?J=C3=BCrgen?= Urban , gcc-patches@gcc.gnu.org Subject: Re: Support for MIPS r5900 References: <20130106225645.190700@gmx.net> <50EB0294.8070600@redhat.com> Date: Mon, 07 Jan 2013 20:44:00 -0000 In-Reply-To: <50EB0294.8070600@redhat.com> (Jeff Law's message of "Mon, 07 Jan 2013 10:15:00 -0700") Message-ID: <8762384tbe.fsf@talisman.default> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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/msg00357.txt.bz2 Jeff Law writes: > On 01/06/2013 03:56 PM, "J=C3=BCrgen Urban" wrote: >> Hello, >> >> I created a patch from scratch to support MIPS r5900 used in the >> Playstation 2, but I have some problems with it. The attached patch >> only works with the latest binutils from CVS. The binutils forces the >> compiler to use r5900 compatible instructions which is good to find >> errors in the GCC. Later I will try to submit a patch here, but first >> I need some help. The MIPS r5900 supports 32 bit, 64 bit and 128 bit >> data accesses on a 32 Bit address bus. It supports instructions from >> MIPS ISA I, II, III, IV and has additional instructions, but none of >> them are complete. On each ISA level there are instructions missing. >> It can run MIPS ABI o32, n32 and o64 code, as long as unsupported >> instructions are not used or emulated by the operating system and the >> addresses keep in the first 32 bit. My patch adds support for r5900 >> and tries to disable the following unsupported instructions: ll, sc, >> dmult, ddiv, cvt.w.s, 64 bit FPU instructions. ll and sc is disabled >> with "-mno-llsc" and works. cvt.w.s is replaced by trunc.w.s. This >> seems to work. 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. I >> tried to disable dmult and ddiv (see mips.md). Disabling worked, but >> now muldi3 calls itself in libgcc2. I thought this should work, >> because I got this working with GCC 4.3, but the latest GCC version >> is a problem. multi3 is calling muldi3, so that muldi3 should be able >> to use mulsi3, because it is the same C code in libgcc2. Can someone >> get me some hints or comments? How can this be debugged? >> >> Does someone know how to enable TImode in MIPS ABI o32 (this doesn't >> need to use the 128 bit instructions at the moment)? There is some >> old code for the Playstation 2 which needs this. I know that TImode >> is supported in ABI n32, but some code uses also the 32 bit FPU and >> FPU registers are not available with "-msoft-float" in inline >> assembler. >> >> What is the best way to change the alignment to 128 bit for all >> structures and stack in any MIPS ABI? Much old code for the >> Playstation 2 expects this. > Hmm, I did a R5900 port back in the late 90s... Did that port never get= =20 > contributed (yes, my memory is that bad these days) I remember there was talk in the early 2000s of contributing it, but we never had time. I think the MIPS copro support was from the r5900 port -- so it's effectively dead at the moment -- and the MODE_HAS_* stuff was from a refresh of it. Both of those made their way in, but I think that was about it. Richard