Thanks. The bit im not sure about is how to prevent ending up Ina state in the middle of a single instruction if one instruction gets split into multiple uops. Like if one instruction gets split into two uops and the first one completes but the second one raises an exception.
OK, let me try (Tuna-Fish, put me right at any point).
> Like if one instruction gets split into two uops and the first one completes but the second one raises an exception.
That's not a problem. It's just one of n exception types that instruction can raise. Suppose a macro (say x64 instruction, if something like this exists) division instruction where one operand could be fetched from memory, you could have
r2 <- r3 / ^r4
where ^r4 fetches the contents of memory at address held in r4.
suppose it's split up into u-ops
tr6 <- ^r4 ;; tr6 is temporary register 6, invisible to programmer
r2 <- r3 / tr6
you could have a division by zero at u-op 2, or an invalid address exception for u-op 1. Either of those are valid exceptions for the original single macro-op.
Extrapolating from what Tuna-Fish said, the ROB is list of macro instructions, each instruction I assume will be tagged with its actual macro-op address, and each u-op must link back to the originating macro-op so macro-op retirement can take place, so we have a small (8 bit? Because ROB queue is small) pointer from each u-op back into the macro-op in the ROB.
Follow the 8-bit u-op ptr to the ROB, get the originating macro-op address, raise exception at that address.
Assuming I'm right, and assuming I understood you question correctly. I'll have to read his answer more carefully again.
edit: swapped ^ for asterisk as deref operation, as stars interpreted as formatting. Edit 2: slightly clearer.
