On Sun, 2012-04-22 at 09:06 +0100, R. Diez wrote: > > > > 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 would write in the spec "no exception will be raised when a value of 0 is > written to R0". This leaves the door open for any implementation where R0 is > hard-wired to 0 to raise an exception when the software is trying to use R0 > as a normal register. > > I was actually going to suggest a _configurable flag_ in or1ksim in order to > monitor writes to R0 and stop when the value is not zero. This would help > ironing out any software bugs in ABI-conformant software that is forgetting > to initialise R0 or that is writing non-zero values to it. > > With this behaviour, there is no need to make a distinction between > supervisor and user mode. > > I wonder whether this complication is worth it at all. Are there any > implementations out there which hard-wire R0 to 0? If not, we can just let R0 > be a normal register and leave this matter to the ABI specification. I don't > think it's worth protecting the zero value of R0, as many other registers are > equally worth of protection (for example, the stack pointer). >
As far as I'm concerned, the important thing is to know what the rules are: i) if r0 is a regular, call-saved register normally used as fixed-function register with value 0, that's fine; but in this case I need to save and restore it for all context switches. Also, GCC has to initialize it at the start of every new process. ii) if r0 is a special register that you can't write anything but 0 to, then I don't need to bother to save/restore it for context switches That's pretty much what it comes down to. I know I had an argument about using it for funky optimizations... I'm backing down on that point because it's not the win that I'd hoped for. Setting up the kernel stack at a context switch requires some scratch space which I'd hoped to be able to avoid flushing a cache line for... but I'd need 3 scratch registers as it stands today, so having r0 writable isn't sufficient... but I digress, this isn't relevant to this discussion. +1 for all Ruben's suggestions above, they all look good to me... it's just a matter of picking one. Making r0 "unwritable" is probably what matches what we have had historically, so that's probably the best option. /Jonas _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
