On Tue, Mar 20, 2012 at 12:52 PM, Jonas Bonn <[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.


---Matthew Hicks
_______________________________________________
OpenRISC mailing list
[email protected]
http://lists.openrisc.net/listinfo/openrisc

Reply via email to