A ROB / Reorder Buffer is just RAM from my understanding. Since writes are all out of order, the ROB holds the "future values" of things for sections of code that have already executed (due to out-of-order scheduling), that are waiting for "earlier" code to execute.
Ex: If line#105 has been out-of-order executed, and knows that "MemoryLocationX = 100" happens there... the ROB holds it until line#90 through line#014 are done executing.
-----------------
Consistent instruction size would decrease:
* uop cache (AMD / Intel require a uop cache, where "decoded" instructions stay). This is more optional for ARM... and I'd personally expect this to be the "biggest cost" of x86 instructions.
* Decoder (due to the complexity of x86 instructions, the decoder on those chips is probably bigger).
The ROB / Reorder buffer is "after the decoder", probably just interacting with uops directly. I doubt that instruction set size-or-complexity has anything to do with ROB sizes.
A ROB / Reorder Buffer is just RAM from my understanding. Since writes are all out of order, the ROB holds the "future values" of things for sections of code that have already executed (due to out-of-order scheduling), that are waiting for "earlier" code to execute.
Ex: If line#105 has been out-of-order executed, and knows that "MemoryLocationX = 100" happens there... the ROB holds it until line#90 through line#014 are done executing.
-----------------
Consistent instruction size would decrease:
* uop cache (AMD / Intel require a uop cache, where "decoded" instructions stay). This is more optional for ARM... and I'd personally expect this to be the "biggest cost" of x86 instructions.
* Decoder (due to the complexity of x86 instructions, the decoder on those chips is probably bigger).
The ROB / Reorder buffer is "after the decoder", probably just interacting with uops directly. I doubt that instruction set size-or-complexity has anything to do with ROB sizes.