Say we have a modern (Skylake, say) Intel CPU running at a fixed 5GHz clock rate. Since Intel CPUs run micro-operations internally and reaches > 1 instructions per cycle, it needs to be able to run more than one micro-operation per cycle. But from how registers work we know that new data can only be stored and computation allowed to proceed at certain points of each clock cycle (e.g. the rising edge). Since the CPU internally does more than 1 micro-operation in sequence within a single clock cycle, doesn't that mean it would also need to have more than one internal clock cycle per "external" clock cycle, and hence an internal clock rate that is higher than the listed 5GHz?
Add a comment
|
1 Answer
$\begingroup$
$\endgroup$
That's not necessary, and also not how it is actually done. The way Skylake and most other microarchitectures executes multiple instructions in the same cycle is in parallel, not in sequence within a cycle.
So the registers would not be read at several different moments during a cycle, instead several reads are done simultaneously. That does not present a structural hazard: the read logic can be duplicated, as in multi-ported SRAM. Clearly such duplication is not free, but it can be kept in check by exploiting the fact that most registers being read are "hot" (written to recently) and their value will be supplied by different mechanisms anyway (forwarded just-in-time or captured in the reservation station if applicable). Core2 for example could only read 2+1 different entries from its retirement register file (the +1 is for the special case of a register being used as the index in a SIB-encoded address), but for "hot" registers it had no particular limit (or none that I know of). From SandyBridge onward Intel has been using an alternative organization with more of a tag-indexed physical register file style and there seems to be no particular limit on reading from it (so maybe they just went with plenty of read ports there?). Anyway the TL;DR is that the multiple µops in a cycle and their register reads are not sequential and don't need a faster clock.
NetBurst (Pentium 4) actually did have a faster internal clock for its fast ALUs and AGU, but not for everything (excluding for example the register file), and the reason was not that register reads needed to be sequential (they weren't), just for raw computation speed with low latencies. There were two ALUs, so together they can execute 4 ALU operations per cycle, though the front-end cannot supply them with new operations that quickly so the peak throughput cannot be sustained and is only reached in bursts. It is more complicated than executing two operations per ALU in sequence within a "normal cycle" though. Instructions actually take 3 FLCK cycles, in the first cycle the low 16 bits of the result are computed, in the second cycle the high 16 bits are computed and a dependent instruction can already start (since it would also only compute the low 16 bits of its result in the first cycle, so for now it only needs the low 16 bits of its inputs) and in the third cycle the flags are computed.
