From: Richard Henderson <rth@twiddle.net>
To: openrisc@lists.librecores.org
Subject: [OpenRISC] OpenRISC 1.3 spec
Date: Fri, 12 Apr 2019 22:03:50 -1000 [thread overview]
Message-ID: <935627bf-8feb-1aea-8795-d17e0bfb2f57@twiddle.net> (raw)
In-Reply-To: <CAAfxs77GkWenpN0s1pM_YeVgNZabBx55fCqLfxoMffTSa-E=cw@mail.gmail.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="maccentraleurope", Size: 1283 bytes --]
On 4/12/19 10:56 AM, Stafford Horne wrote:
> I propose to incorporate the following into the openrisc spec.
>
> Use proposals
>
> P6 https://openrisc.io/proposals/lfmadd - clarification on internal rounding
> (possibly exclude new madd instructions)
> P7 https://openrisc.io/proposals/lstod-ldtos - convert between double and float
> P9 https://openrisc.io/proposals/ladrp - New instruction for PIC code (already
> in binutils)
> P14 https://openrisc.io/proposals/orfpx64a32 - 64-bit fpu implemented in
> marocchino (gcc/bintuils patches under review)
> P11 https://openrisc.io/proposals/lfsf - add support for 'unordered' compares
> P13 https://openrisc.io/proposals/corrections - various corrections (possibly
> exclude correction for l.ext* being mandatory as its not implemented everywhere)
As long as we're making changes, I propose to adjust ORFPX32 for OR64 such that
the 32-bit result written back to the 64-bit register has the upper bits
written as 0xffffffff.
For RISC-V this is called "NaN-boxing". It means that if you attempt to use an
f32 result as an f64 input you'll get an exception, since the input will be a
Signaling NaN.
It's not complete, as we have not defined a 32-bit load that fills in
0xffffffff_00000000, but it'll get many incorrect uses.
r~
next prev parent reply other threads:[~2019-04-13 8:03 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-12 20:56 [OpenRISC] OpenRISC 1.3 spec Stafford Horne
2019-04-12 21:17 ` Richard Henderson
2019-04-12 21:48 ` Stafford Horne
2019-04-13 8:11 ` Richard Henderson
2019-04-13 8:47 ` Stafford Horne
2019-04-14 9:41 ` BAndViG
2019-04-25 21:17 ` Stafford Horne
2019-04-26 22:22 ` Stafford Horne
2019-05-02 12:22 ` BAndViG
2019-05-07 15:28 ` Richard Henderson
2019-05-07 21:12 ` Stafford Horne
2019-05-08 18:05 ` BAndViG
2019-05-09 20:29 ` Stafford Horne
2019-05-09 21:47 ` Richard Henderson
2019-05-10 7:56 ` BAndViG
2019-05-11 10:04 ` Stafford Horne
2019-05-12 19:58 ` BAndViG
2019-05-12 23:09 ` Stafford Horne
2019-06-06 22:11 ` Stafford Horne
2019-06-15 6:14 ` Stafford Horne
2019-04-13 8:03 ` Richard Henderson [this message]
2019-04-14 6:30 ` Stafford Horne
2019-04-14 6:48 ` Stafford Horne
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=935627bf-8feb-1aea-8795-d17e0bfb2f57@twiddle.net \
--to=rth@twiddle.net \
--cc=openrisc@lists.librecores.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.