3 ms·
From the programmers point of view only the working registers are really important, other registers are just OS related (MSR), some are really important, but th
by andy_threos_io 6y ago
From the programmers point of view only the working registers are really important, other registers are just OS related (MSR), some are really important, but the internal representation may be total different.
Like a mode switch bit in a CR register. So MSR-r are just the interface. And the MSR register access can be "slow", so no synchronization or optimization required.
But, the idea of more register makes better architecture, is a total bad assumption. See the dead body of Itanium (128 general-purpose 64 bit integer registers, 128 floating point registers etc. )
With multitasking, one have to switch between context, and larger context (register file size) takes more time.
There are cases when you are better using just the GPRs, rather than the SIMD registers. (Linux kernel does not use FPU or SIMD registers)
Also SIMD usage may slow down the clock, like AVX in x86_64. So you may trust your compiler for vectorization, but it may make more harm than good.
- bluetomcat 6y agoMore GPRs visible in the ISA also means more bits needed to encode instructions. If instruction length and encoding were not an issue, I bet we would have seen memory-to-memory ISAs where no GPRs exist, only instructions referencing memory locations. The dynamic register file would then be just a level below L1 cache, or even completely removed.
- mr_toad 6y ago> With multitasking, one have to switch between context, and larger context (register file size) takes more time. Sparc chips got around that by having sliding windows of registers: instead of having to push all the registers to the stack you just moved the window.
- deleted 6y ago[deleted]
- nine_k 6y agoIMHO what killed itanium wasn't too many registers, and not even compiler difficulties — it was an attempt to have a working x86 emulation. So, instead of a weird but very fast CPU, it ended up being not very fast both in x86 and native modes, while still being weird. (The makers of the Cell CPU did not compromise, went full weird, and had a winner of sorts.)