From: Richard Sandiford <rdsandiford@googlemail.com>
To: "Maciej W. Rozycki" <macro@codesourcery.com>
Cc: "Jürgen Urban" <JuergenUrban@gmx.de>, gcc-patches@gcc.gnu.org
Subject: Re: Support for MIPS r5900
Date: Tue, 08 Jan 2013 07:28:00 -0000 [thread overview]
Message-ID: <87ip782kxl.fsf@talisman.default> (raw)
In-Reply-To: <alpine.DEB.1.10.1301072351450.4834@tp.orcam.me.uk> (Maciej W. Rozycki's message of "Tue, 8 Jan 2013 00:23:22 +0000")
"Maciej W. Rozycki" <macro@codesourcery.com> writes:
>> > 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.
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.
Richard
next prev parent reply other threads:[~2013-01-08 7:28 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 [this message]
2013-01-08 17:24 ` Maciej W. Rozycki
2013-01-08 18:25 ` Richard Sandiford
2013-01-08 22:34 ` "Jürgen Urban"
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=87ip782kxl.fsf@talisman.default \
--to=rdsandiford@googlemail.com \
--cc=JuergenUrban@gmx.de \
--cc=gcc-patches@gcc.gnu.org \
--cc=macro@codesourcery.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).