public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: "\"Jürgen Urban\"" <JuergenUrban@gmx.de>
To: "Maciej W. Rozycki" <macro@codesourcery.com>,
	rdsandiford@googlemail.com, JuergenUrban@gmx.de
Cc: gcc-patches@gcc.gnu.org
Subject: Re: Support for MIPS r5900
Date: Tue, 08 Jan 2013 22:34:00 -0000	[thread overview]
Message-ID: <20130108223433.27430@gmx.net> (raw)
In-Reply-To: <alpine.DEB.1.10.1301072351450.4834@tp.orcam.me.uk>

Hello Maciej,

> > > 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.
> > 
> > Probably showing my ignorance, but I couldn't see this in the patch.
> 
>  This has raised my attention -- AFAICS the binutils change recently 
> approved correctly disables DMULT, DDIV, CVT.W.S, etc. for -march=r5900, 
> but does not do that for LL or SC.  I think that should be fixed.  And I 
> gather LLD and SCD should then be disabled as well.

The glibc can only be compiled with support for ll and sc. The Linux kernel successfully emulates these instructions. When compiling GCC for mips*r5900*-elf (i.e. not Linux), the instructions ll/sc and lld/scd are disabled by my patch.

>  Things would get more complicated if one wanted to run a real OS such as 
> Linux on the R5900 and let the kernel FP emulator handle the missing 
> double FP automagically -- this is a little bit out of scope here as 
> regular -mdouble-float would then just do, but makes me wonder whether 
> -mfp32 should really be enforced (as opposed to just defaulted) for the 
> R5900, hmm...

I tried to emulate the 64 Bit FPU when the real 32 Bit FPU was enabled in Linux. There are 2 problems with this:
1. When the program starts, I don't know if it needs a 64 Bit or 32 Bit FPRs. So registers are initialized for 32 bit. When dmfc0 or dmtc0 appears, I need to emulate them using 32 Bit FPU, because some 32 bit programs use these instructions with a 32 Bit FPU (e.g. Linux 2.6.35 kernel and Debian 5.0). When a 64 bit calculation instructions appears, I need to switch from 32 bit FPRs to 64 bit FPRs. When the program used 32 bit instructions with the odd FPRs, there is no way to reconstruct the overwritten part of the 64 bit FPRs.
2. Some undefined instructions (e.g. c.eq.d) doesn't lead to an exception on an r5900, but have undefined behavior. So there is no emulation possible. It just calculates random stuff.
So the FPU needs to be disabled and completely emulated by the kernel, because then all FPU instructions lead to an exception. This is working with Linux 2.6 on PS2.
There are even more problems when running unchanged code from official Fedora 12 on PS2, because of some different opcode encoding. The users of my PS2 Linux 2.6 complain about low speed, because many instructions are emulated. I need some fast implementation, even if the size of the floating point data types is smaller. So 32 bit FPU must be default for r5900.

Best regards
Jürgen

  parent reply	other threads:[~2013-01-08 22:34 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-06 22:57 "Jürgen Urban"
2013-01-07 17:15 ` Jeff Law
2013-01-07 20:44   ` Richard Sandiford
2013-01-07 21:52 ` Richard Sandiford
2013-01-08  0:23   ` Maciej W. Rozycki
2013-01-08  7:28     ` Richard Sandiford
2013-01-08 17:24       ` Maciej W. Rozycki
2013-01-08 18:25         ` Richard Sandiford
2013-01-08 22:34     ` "Jürgen Urban" [this message]
2013-01-10 23:25       ` Maciej W. Rozycki
2013-01-11  9:49         ` Richard Sandiford
2013-01-11 16:55           ` Maciej W. Rozycki
2013-01-13 14:16         ` "Jürgen Urban"
2013-01-14 18:42           ` Maciej W. Rozycki
2013-01-17 22:21             ` "Jürgen Urban"
2013-01-17 23:23               ` Maciej W. Rozycki
2013-01-19 10:53                 ` Richard Sandiford
2013-01-20 21:43                 ` "Jürgen Urban"
2013-01-08  4:22   ` Jeff Law
2013-01-08  7:22     ` Richard Sandiford
2013-01-08 22:49       ` "Jürgen Urban"
2013-01-09  5:25         ` Jeff Law
2013-01-10 22:59           ` "Jürgen Urban"
2013-01-11  4:41             ` Jeff Law
2013-01-08  7:16   ` Richard Sandiford
2013-01-08 21:30   ` "Jürgen Urban"

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130108223433.27430@gmx.net \
    --to=juergenurban@gmx.de \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=macro@codesourcery.com \
    --cc=rdsandiford@googlemail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).