4 ms·

Not likely. The big advantage of this and similar proposals is they replace the massive register file renaming needs with something much more efficient in chip

Not likely. The big advantage of this and similar proposals is they replace the massive register file renaming needs with something much more efficient in chip area. It's not just the number of registers/positions, it's that renaming forces a register file with a ton of ports, where chip area grows as the square of number of ports. So a chip that had both physical structures would be very area inefficient, and this is unlikely to be a win on cost, performance, or power.

ithkuil 3y ago
it's not just area, it's also powering the machinery. If you could turn it off for workloads that don't need it, you could achieve a reducing in power consumption. It would be better to also save the area, but perhaps a tradeoff if worth it?
- rbanffy 3y ago
  Unpowered silicon is great for power management as well. In order to heat up the chip, you'll also need to heat up those dark areas, allowing you to push more power for longer (in comparison with a design with zero spare transistors).
  - Dylan16807 3y ago
    If you want area that's dedicated to being "dark", put cache there.
ajb 3y ago
You only need a renamer for out-of-order issue - I guess you could execute a backward compatible ISA using only in-order issue. Still, it doesn't strike me as very likely to be implemented in that way.
- rbanffy 3y ago
  > I guess you could execute a backward compatible ISA using only in-order issue. We did that for a very long time.
  - ajb 3y ago
    Do you mean, there were CPUs with 2 ISAs, one in-order and one out of order? Which ones, if you can say?
    - rbanffy 3y ago
      A modern x86 runs machine code out of order while an older Atom runs it jn order.
      - ajb 3y ago
        I think we are talking at cross purposes. I assumed that everyone who has followed the discussion so far knew about in order implementations of a single ISA, which they all were, originally.
ralferoo 3y ago
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!)
- rbanffy 3y ago
  > there is no need to renaming as the next instruction knows that the register is already updated. Still some complications arising from the second instruction being dependent on the first and needing to be issued to an execution unit after the first one.

ithkuil 3y ago

it's not just area, it's also powering the machinery. If you could turn it off for workloads that don't need it, you could achieve a reducing in power consumption. It would be better to also save the area, but perhaps a tradeoff if worth it?

rbanffy 3y ago
Unpowered silicon is great for power management as well. In order to heat up the chip, you'll also need to heat up those dark areas, allowing you to push more power for longer (in comparison with a design with zero spare transistors).
- Dylan16807 3y ago
  If you want area that's dedicated to being "dark", put cache there.

ajb 3y ago

You only need a renamer for out-of-order issue - I guess you could execute a backward compatible ISA using only in-order issue. Still, it doesn't strike me as very likely to be implemented in that way.

rbanffy 3y ago
> I guess you could execute a backward compatible ISA using only in-order issue. We did that for a very long time.
- ajb 3y ago
  Do you mean, there were CPUs with 2 ISAs, one in-order and one out of order? Which ones, if you can say?
  - rbanffy 3y ago
    A modern x86 runs machine code out of order while an older Atom runs it jn order.
    - ajb 3y ago
      I think we are talking at cross purposes. I assumed that everyone who has followed the discussion so far knew about in order implementations of a single ISA, which they all were, originally.

ralferoo 3y ago

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!)

rbanffy 3y ago
> there is no need to renaming as the next instruction knows that the register is already updated. Still some complications arising from the second instruction being dependent on the first and needing to be issued to an execution unit after the first one.