On Sun, Apr 22, 2012 at 9:37 AM, Jonas Bonn <[email protected]> wrote: > > 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.
Making it "unwritable" is what we had as far as the ABI was concerned, but not what the hardware did. Any hypothetical older implementations which may have hardwired this guy to zero shouldn't be raising exceptions if its written to (although that was never specifically mandated either way) and I don't think we should be fussing over this case too much anyway. Any other implementation was quite likely to have implemented the register file as a memory and so it'd just be like any other register. I'm for making it just another general purpose register (in implementation terms) and specify in the C ABI section that it's used as constant zero. That's as simple as possible. Julius _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
