2

I have some doubts on Instruction pipelining.

I have an assembly

0x111: div    %ecx
0x112: add    $0x13,%ecx  #The address 112 is not real, I just kept to show that there is no instructions between div and add

The program counter,RIP points to 0x111. My doubt is that will the processor execute(instruction pipelining or order change / Any reason) 0x112's instruction while RIP is at 0x111. If I stop the execution at RIP 0x111, is there any chance that 0x112 is executed and %ecx value is 0X13?

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
Franc
  • 319
  • 9
  • 28
  • 2
    `div %ecx` is 2 bytes long, but let's pretend it's a 1-byte instruction like `push %rcx` (which like div reads RCX) for the purposes of your toy example, that's fine. – Peter Cordes Mar 17 '21 at 16:15

1 Answers1

7

No. The general rule is that features like pipelining are completely transparent to any single thread of execution (i.e. a single core), and that the CPU ensures that everything appears exactly as if the instructions had been executed sequentially in program order, except maybe faster. If execution stops at address 0x112, whether due to an interrupt or breakpoint or any other reason, you will see %ecx containing the result of the div but without the added 0x13.

It's possible that internally, the machine had gone ahead and executed the add already, perhaps using some unnamed internal registers, but if so then the machine is responsible for "rolling back" this execution, so that the architectural register %ecx contains what it is supposed to by the time you are able to inspect it.

Pipelining and other sorts of execution/memory reordering are relevant when thinking about performance, but not when thinking about what the program actually does. The exception is in multi-threaded programs, since due to such features, memory accesses performed by one thread may not be seen in the same order by other threads, and one may need barriers in certain cases where this ordering is important. But to be clear, this does not apply to single-threaded programs.

Nate Eldredge
  • 48,811
  • 6
  • 54
  • 82
  • 1
    That's a (useful) oversimplifiation: execution ordering is not the same thing as memory ordering. Store-address and store-data uops can fully execute out of order, but the store buffer makes sure they stores only commit to L1d cache in program order. And [OoO speculative early exec of loads is checked by the memory order buffer in Intel CPUs](https://stackoverflow.com/questions/55563077/why-flush-the-pipeline-for-memory-order-violation-caused-by-other-logical-proces) - [Can out-of-order execution lead to speculative memory accesses?](https://stackoverflow.com/a/65492037) – Peter Cordes Mar 17 '21 at 16:22
  • 1
    In CPU-architecture terminology, "precise exceptions" is the feature that allows us to stop with a debugger or external interrupt at some arbitrary point and see a consistent state *as if* execution had happened in program order. This is why retirement from the out-of-order back-end is done in program order. (There have been proposals for ways to avoid in-order retirement, like KIP, the Kilo-Instruction processor: https://www.csl.cornell.edu/~martinez/doc/taco04.pdf. People have wondered if Apple's M1 might be doing something like that, instead of having a huge ROB to hide that much latency.) – Peter Cordes Mar 17 '21 at 16:24
  • 1
    Also note that you can have memory reordering *without* OoO exec: [Are memory barriers needed because of cpu out of order execution or because of cache consistency problem?](https://stackoverflow.com/q/63970362). (e.g. hit-under-miss caches with scoreboarded loads, and weakly-ordered store buffers. Or for StoreLoad reordering, merely having a store buffer at all). [Can a speculatively executed CPU branch contain opcodes that access RAM?](https://stackoverflow.com/q/64141366) – Peter Cordes Mar 17 '21 at 16:36
  • Good to know. So maybe I should just refer to "pipelining and other sorts of execution/memory reordering"? – Nate Eldredge Mar 17 '21 at 16:50