3 ms·
As I understand it, if you are going to go out of order, a large number of architectural registers is actually a handicap; it costs more resources to map them t
by rwallace 8y ago
As I understand it, if you are going to go out of order, a large number of architectural registers is actually a handicap; it costs more resources to map them to physical registers.
Given that, was it the right choice to go with thirty-two architectural integer registers? Sixteen registers would be mostly adequate, and would seem to make it easier to implement out of order. What am I missing?
- titzer 8y ago> As I understand it, if you are going to go out of order, a large number of architectural registers is actually a handicap; it costs more resources to map them to physical registers. Hmm, I doubt it. You need at least as many hardware registers as reorder buffer entries, which these days is 100+. The only thing I could think of would be extra space for checkpoint entries inserted into the ROB slot having more bits, and generally more bits to encode register indexes. Besides that, more hardware registers means more ILP available to the compiler before it starts spilling to the stack, which is overall a good thing, since it gives the OOE more instructions that have explicit data dependencies through registers rather than implicitly through spill slots.