On Sat, 2012-04-21 at 16:13 +0100, Julius Baxter wrote:
> On Sat, Apr 21, 2012 at 4:05 PM, R. Diez <[email protected]> wrote:
> >
> >
> >> I've posted my proposed change to the architecture spec on the wiki:
> >> http://opencores.org/or1k/Architecture_Specification#GPR0_usage.2C_implementation
> >
> > The change you've proposed in the Wiki makes the specification incompatible 
> > with any implementation that actually hard-wires R0 to 0, which is allowed 
> > according to the original spec, because the software is free to use the 
> > OpenRISC CPU but not the C ABI. I don't think the spec should force the 
> > l.movhi instruction either, the software should be free to use whatever 
> > means it wants to clear R0.
> >
> > I would mention in the new spec that an implementation may have hard-wired 
> > R0 to 0, and that writing 0 to R0 should not raise an exception on those 
> > implementations.
> 
> Fair enough. Proposal has been updated.

I wish you'd post the text here instead of making me copy it from the
wiki:

WIKI: "R0 is used as a constant zero according to the ABI. R0 may or may
not be hard-wired to zero in implementation. In the case where it is
hard-wired to zero, no exception will be raised when it is used as a
destination register."

I know an earlier statement I made may be the cause of this wording, but I've 
changed my mind.

I think r0 should be no-op when not in supervisor mode:  no exception, but also 
no effect.  r0 retains its value (presumably 0).

Is that doable?  It only needs to writable in supervisor mode so that you can 
clear thing at startup.

WIKI: The following paragraph should be added to the ABI section on
GPR0's usage:

WIKI: "R0 is used as a constant zero. If the register is not hard-wired to zero 
it should be cleared 
by software on reset, eg. l.movhi r0,0."

The ABI section should not go into implementation details.  "R0 is used as a 
constant zero".  That's enough.

The bit about clearing the register should go into the earlier section as 
that's an implementation detail.

/Jonas

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

Reply via email to