From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stafford Horne Date: Mon, 13 May 2019 08:09:13 +0900 Subject: [OpenRISC] OpenRISC 1.3 spec In-Reply-To: References: <20190412214843.GB32284@lianli.shorne-pla.net> <05413d8c-395c-de51-95f6-cdaa85c834dd@twiddle.net> <20190413084708.GC32284@lianli.shorne-pla.net> <3D70BAC7A5B64C0E977D84EC118F146E@BAndViG> <20190425211702.GG32284@lianli.shorne-pla.net> <20190507211254.GD11006@lianli.shorne-pla.net> <6CFC558D2E0643BAA8C0CFCB1AEE95BB@BAndViG> <3ce42625-83fe-4ee2-b48f-23e6362ee616@twiddle.net> <20190511100433.GA20465@lianli.shorne-pla.net> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: openrisc@lists.librecores.org On Mon, May 13, 2019, 4:58 AM BAndViG wrote: > > 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? > I think we can merge. It will take time to get it all upstream. Note I started updates to the spec. - https://github.com/stffrdhrn/doc Still a lot to do, but if you want to look at how I wrote up the lf sfu* instructions please let me know what you think -stafford -------------- next part -------------- An HTML attachment was scrubbed... URL: