On 03/20/2012 09:14 PM, Matthew Hicks wrote:
On Tue, Mar 20, 2012 at 12:52 PM, Jonas Bonn <[email protected]
<mailto:[email protected]>> wrote:
On Tue, 2012-03-20 at 19:43 +0200, Stefan Kristiansson wrote:
> On 03/20/2012 03:50 PM, Jonas Bonn wrote:
> >
> > I don't agree... in the same way that you don't have to respect any ABI
> > as long as you aren't calling into "external" code, you are free to
> > fiddle with r0 as much as you want. "r0 contains 0" is ABI, it is not a
> > hardware detail. A bit weird, I agree, but not fundamentally incorrect.
> >
> > The real problem is that r0 isn't _necessarily_ writable... so there's
> > no guarantee that you can actually run a program that changes r0 on an
> > arbitrary implementation.
> >
> >
>
> No, the real problem is that the specification is not clear about
> whether it should be possible to do a write to r0 without any side effects
> (regardless if the value actually will be written or not to r0).
>
> Like it is now it's freely up to the reader to do an implementation
> that locks up the cpu when someone tries to write 0 to r0.
> Although it perhaps wouldn't be a very good implementation ;)
>
Yeah, fair enough. I guess the ambiguity kills whatever advantage the
flexibility may give you (dubious though it may be).
R Diez's text is fine... might be even better to go a step further and
be explicit about the requirements/limitations of r0 (i.e. writing to r0
is a no-op; r0 is not guaranteed to contain 0 at startup; etc...)
We had a discussion about this in December 2011. I submitted a patch that
would basically treat any write to r0 as if the value to be written is 0.
Most felt that changing the ISA would be an unacceptable ABI break and the
patch was not accepted.
That's a truth with modification, isn't it?
You proposed changing an implementation (or1200) not the ISA,
and most felt it wasn't worth it since it could as well (and should) be handled
in software.
I don't think there was any discussion about unacceptable ABI breaks and
changing ISAs.
Stefan
_______________________________________________
OpenRISC mailing list
[email protected]
http://lists.openrisc.net/listinfo/openrisc
