From: BAndViG <bandvig@mail.ru>
To: openrisc@lists.librecores.org
Subject: [OpenRISC] OpenRISC 1.3 spec
Date: Sun, 12 May 2019 22:58:53 +0300 [thread overview]
Message-ID: <A49361B4A05048AD995FF588CC923E61@BAndViG> (raw)
In-Reply-To: <20190511100433.GA20465@lianli.shorne-pla.net>
> From: Stafford Horne
> Sent: Saturday, May 11, 2019 1:04 PM
> > On Fri, May 10, 2019 at 10:56:05AM +0300, BAndViG wrote:
> > I've been thinking about a variants for R0 write protection. R0 could be
> > zero initialized at cpu_rst by dedicated circuits. And `invalid
> > instruction`
> > exception should be raised if an instruction tries to write to R0. At the
> > same time such behavior is incompatible with current run-time
> > initialization
> > sequences implemented in OR1K tool chains. The circle is closed.
> We still have the option to drop the validation. Just as we don't have
> validation for writing to r0, I think its fine to say r31's pair register is
> undefined and should be avoided. (i.e. on some machines it might go into the
> shadow reg space)
On the one hand I'm a kind of perfectionist and would prefer to implement such
protections. On the other hand they cost noticeable space and timing. Not
trivial choice for me :).
> On the other hand, I have finished the GCC updates for unordered comparisons.
> You can see the patch here, I built newlib with this enabled and was able to
> shake out a few bugs. It seems to work:
> - https://github.com/stffrdhrn/gcc/commits/or1k-fpu-2
> The new gcc argument is:
> -munordered-float
I've build two variants of GCC9/NewLIB tool chains. One has got
"-mhard-float -munordered-float" options raised by default. And another one has
got "-mhard-float -mdouble-float -munordered-float" default options. First
variant was used to build single precision Whetstone for mor1kx+FPU32 and
second to build single and double precision Whetstone for MAROCCHINO. All
variants work.
We could merge fp_unordered_cmp branches into master. Or should we postpone the
merge till your binutils/gcc patches being upstreamed?
WBR
Andrey
next prev parent reply other threads:[~2019-05-12 19:58 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 [this message]
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
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=A49361B4A05048AD995FF588CC923E61@BAndViG \
--to=bandvig@mail.ru \
--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.