On Sun, Mar 25, 2012 at 12:29 PM, Julius Baxter <[email protected]> wrote: > On Tue, Mar 20, 2012 at 3:10 PM, R. Diez <[email protected]> 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 architecture specification document does not currently distinguish well >> between CPU core specification and ABI specification with regards to R0. How >> about we change the document to say, on the CPU specification side: "R0 may >> be hard-wired to zero", and then move the "R0 is used as a constant zero" >> statement to the ABI specification. >> >> The CPU specification states that "R0 should never be used as a destination >> register". This is problematic as it could be interpreted as "the CPU can >> generate an exception if the user tries to write to R0". Generic software >> may not know whether the CPU allows non-zero values in R0, so we should >> specify a safe way to deal with R0 on start-up. >> >> There are 2 options I can think of: >> >> 1) Add to the CPU specification this: "Therefore, writing to R0 is allowed >> but may have no effect". >> >> 2) Provide in the specification a safe way to clear R0 on start-up if not >> already zero. The document should state then something along this line: >> >> The standard software ABI requires R0 to be zero. In order to clear R0 >> safely, standard ABI software should read R0's value on start-up, and then: >> >> a) If the value is already zero, the software must not write to R0, as that >> could generate a CPU exception. >> >> b) If the value is not already zero, the software shold write value zero to >> R0, and that must not generate a CPU exception. >> >> I guess there should be no room in the CPU specification for R0 not being >> writeable and not being zero at the same time, as that would invalidate the >> API specification. It is then implementation specific whether the CPU allows >> writing non-zero values to R0. >> > > Interesting discussion so far. > > It looks like the ISA is, on one hand, going too far by saying r0 > should be 'used as a constant zero' (should probably be in the ABI) > but then not far enough when saying '[w]hether or not R0 is actually > hardwired to zero is implementation dependent' by leaving out a > description of what happens if you write to it when it's hardwired to > zero. > > I reckon we clean this up by removing all reference to r0 being zero > or hardwired in section 4.4 (ISA spec) and put rules about clearing r0 > at startup and then never using it as a destination register again. > This results in an implementation where r0 is just like the other 31 > GPRs (the most likely scenario for an implementation.)
Sorry - I meant "put rules _in the ABI_ about clearing r0 at startup and then never using it as a destination register again." Julius _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
