I'm not really sure this is true. The reason you need register renaming is because of pipelines and variable execution timings. However, it should be fine to ha

I'm not really sure this is true. The reason you need register renaming is because of pipelines and variable execution timings. However, it should be fine to have some single-cycle load/store instructions that move data between the rotating and non-rotating register files - because if those instructions are single cycle, there is no need to renaming as the next instruction knows that the register is already updated. In some ways, this isn't really needed - you could spill registers to the stack, but having a non-rotating register file means you can avoid actually writing these out to memory. In many ways, the SPARC register file solution would be appropriate here too, as then you completely avoid the notion of caller/callee saved whilst also avoiding actually having to store temporaries on the stack at all, unless a certain function depth is reached. (EDIT: just re-read the document, and I guess a callee is free to never use the "v hand", and so it wouldn't need to save those registers either, so maybe this is sufficient.) But I think having a non-rotating register file is useful, otherwise you'll incur penalties for branching code as you'll now either have divergent code paths that factor in the different register offsets, or you'll have a load of code wasting cycles just to move all the registers back where you expect them. (EDIT EDIT: after thinking about it more, I think the 4 hands approach actually neatly solves many of problems I envisaged - the conditional code paths can just use a different hand and re-converge execution with another hand register file being correct. I think I actually quite like this idea!)