5 ms·

> [1] I will make one ISA propsal: x86_64 should have had 32 instead of 16 registers, but 16 registers at least is quite a bit better than the 4-8 registers the

> [1] I will make one ISA propsal: x86_64 should have had 32 instead of 16 registers, but 16 registers at least is quite a bit better than the 4-8 registers the 386 had. Is "registers" still a real thing or its just an illusion at this point? I am pretty sure there are "virtual" registers or micro instructions (something like that, I forgot the terminology)

inkyoto 1mo ago
Registers are very much real, and their number being available at the ISA level will continue to matter regardless of the actual number of shadow registers. Being able to store, e.g. 10 vs 5, local variables in a larger register file has performance implications[0] strong enough to consider larger register files an advantage. [0] The reduced number of memory-to-CPU and vice versa data transfers for transient computation results.
RetroTechie 1mo ago
> Is "registers" still a real thing or its just an illusion at this point? I am pretty sure there are "virtual" registers or micro instructions (something like that, I forgot the terminology) https://en.wikipedia.org/wiki/Register_renaming https://en.wikipedia.org/wiki/Register_renaming ? But yes, register count is still a thing. Why? If you run out of registers, operations 'spill out' into main memory. Read: L1 (data) cache. Which is fast, but not as fast as CPU registers. And probably uses a lot more transistors & power. Of course there's limits to that due to # of opcode bits available (eg. 32 regs, 3-operand instruction -> 15 bits needed to encode source & target registers).
- anon-3988 1mo ago
  > But yes, register count is still a thing. Why? If you run out of registers, operations 'spill out' into main memory. Read: L1 (data) cache. Which is fast, but not as fast as CPU registers. And probably uses a lot more transistors & power. Yes, register renaming. What I mean is that why does anyone care still what instruction I am running on? The CPU have its own microops, instruction decoder, its own pipeline, scheduler, etc etc Why can't you have a CPU that have 1024 registers and pretend that it only have 32?
  - peterfirefly 29d ago
    1024 is stretching it a bit but several hundred are normal for high-end CPUs -- while pretending to have 32 (+ usually 32 SIMD registers that may or may not overlap with the normal 32). "[...] and pretend that it only have [sic] 32" is EXACTLY what register renaming is.
peterfirefly 29d ago
They are real on slow CPUs and an illusion on medium to fast CPUs where they are just "value names" (register renaming, physical vs virtual registers). You can still run out of value names, though. We rarely run out of them in straight-line code, we sometimes run out in absurd loop code, and we almost always have to do something for our function calls/returns to avoid running out -- we can't just assign each function its own set of value names. This means we need spill/restore instructions, either before and after the call instruction or at the beginning and end of the function. Sometimes both. We also divide our value names into parts that have to be saved by the caller and parts that have to be saved by the callee. Maybe smarter call/return instructions will help a bit in the future by doing multiple register renames as part of a single instruction in order to make those spills/reloads faster/less necessary/more asynchronous. Sparc and Itanic tried to do something like that (register stacks), but in a way that ended up being expensive to implement in hardware (high clock speeds were hard) and inflexible in practice -- and also annoying to support for the OS, the compiler, and the debugger.

inkyoto 1mo ago

Registers are very much real, and their number being available at the ISA level will continue to matter regardless of the actual number of shadow registers. Being able to store, e.g. 10 vs 5, local variables in a larger register file has performance implications[0] strong enough to consider larger register files an advantage. [0] The reduced number of memory-to-CPU and vice versa data transfers for transient computation results.

RetroTechie 1mo ago

> Is "registers" still a real thing or its just an illusion at this point? I am pretty sure there are "virtual" registers or micro instructions (something like that, I forgot the terminology) https://en.wikipedia.org/wiki/Register_renaming https://en.wikipedia.org/wiki/Register_renaming ? But yes, register count is still a thing. Why? If you run out of registers, operations 'spill out' into main memory. Read: L1 (data) cache. Which is fast, but not as fast as CPU registers. And probably uses a lot more transistors & power. Of course there's limits to that due to # of opcode bits available (eg. 32 regs, 3-operand instruction -> 15 bits needed to encode source & target registers).

anon-3988 1mo ago
> But yes, register count is still a thing. Why? If you run out of registers, operations 'spill out' into main memory. Read: L1 (data) cache. Which is fast, but not as fast as CPU registers. And probably uses a lot more transistors & power. Yes, register renaming. What I mean is that why does anyone care still what instruction I am running on? The CPU have its own microops, instruction decoder, its own pipeline, scheduler, etc etc Why can't you have a CPU that have 1024 registers and pretend that it only have 32?
- peterfirefly 29d ago
  1024 is stretching it a bit but several hundred are normal for high-end CPUs -- while pretending to have 32 (+ usually 32 SIMD registers that may or may not overlap with the normal 32). "[...] and pretend that it only have [sic] 32" is EXACTLY what register renaming is.

peterfirefly 29d ago

They are real on slow CPUs and an illusion on medium to fast CPUs where they are just "value names" (register renaming, physical vs virtual registers). You can still run out of value names, though. We rarely run out of them in straight-line code, we sometimes run out in absurd loop code, and we almost always have to do something for our function calls/returns to avoid running out -- we can't just assign each function its own set of value names. This means we need spill/restore instructions, either before and after the call instruction or at the beginning and end of the function. Sometimes both. We also divide our value names into parts that have to be saved by the caller and parts that have to be saved by the callee. Maybe smarter call/return instructions will help a bit in the future by doing multiple register renames as part of a single instruction in order to make those spills/reloads faster/less necessary/more asynchronous. Sparc and Itanic tried to do something like that (register stacks), but in a way that ended up being expensive to implement in hardware (high clock speeds were hard) and inflexible in practice -- and also annoying to support for the OS, the compiler, and the debugger.