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

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.