> 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. Regards, R. Diez _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
