On Sun, 2012-03-25 at 12:29 +0100, Julius Baxter 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.)
I'd like to throw one more suggestion into this discussion: add a register to indicate whether r0 is writable or hard-wired to 0. If it's not writable, it's a waste to clear it at every syscall and this can be optimized out; if it is writable, then you can use it for clever optimizations (carefully). Then just document r0 as "always 0" per ABI convention, and otherwise effectively just a regular register, with the caveat (as per the above register indication) that it may be not writable at all... Hope that's not too convoluted. /Jonas PS: As for the clever optimization I'm thinking about, it concerns exception entry and that fact that you need to read a cacheline of data from memory now in order to use as scratch space for saving state before you have the kernel context set up... I'm thinking that using r0 (given that you know that it contains 0 anyway) for this might be sufficient and save a cache line load... (this pertaining to Linux, of course) _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
