0

In the context of out of order and dynamic scheduling in the topic of computer architecture, why do store instructions have to wait until they are committed (retired) before they modify memory?

I found an article (http://users.ece.cmu.edu/~schen1/18-741_final_report.pdf) which mentions the following:

Originally, stores are completed as soon as they are issued, but their cache accesses are done in order, when they are completed. The baseline simulator ensures that stores are executed in program order by stalling their cache accesses until the instructions are committed. Unfortunately, this also guarantees that the stores hold their LSQ entries until they are committed, which is long after they have completed.

What I deduced from the above quote is that we need to make stores respect the order of the original program instructions and have them make changes to memory after they are committed, which respects the instructions order of the original program.

Committing or retiring an instruction in this case means to write its destination register, which happens when the instruction is in the reorder buffer.

Mahmoud Mousa Hamad
  • 538
  • 8
  • 21
  • Having stores become visible in program order isn't an inherent requirement; some architectures promise this (e.g. x86) and others do not (most of the rest). – Nate Eldredge Feb 20 '22 at 01:56
  • 2
    What's a more serious issue is that until the instruction retires, it remains uncertain whether it was actually supposed to execute *at all*. A preceding instruction might branch somewhere else, or trap. If it does, then we must ensure that no other core or hardware ever sees the store become visible, because it was never supposed to have happened. – Nate Eldredge Feb 20 '22 at 01:58

0 Answers0