SC in MIPS R10000

• Issues instructions out of program order, but commits in order
  • The problem is with speculatively executed loads: a load may execute and use a value long before it finally commits
  • In the meantime, some other processor may modify that value through a store and the store may commit (i.e. become globally visible) before the load commits: may violate SC (why?)
  • How do you detect such a violation?
  • How do you recover and guarantee an SC execution?
  • Any special consideration for prefetches ? Binding and non-binding prefetches
• In MIPS R10000 a store remains at the head of the active list until it is completed in cache
  • Can we just remove it as soon as it issues and let the other instructions commit (the store can complete from store buffer at a later point)? How far can we go and still guarantee SC?
• The Stanford DASH multiprocessor, on receiving a read reply that is already invalidated, forces the processor to retry that load
  • Why can't it use the value in the cache line and then discard the line?
• Does the cache controller need to take any special action when a line is replaced from the cache?

Relaxed Models

• Implementing SC requires complex hardware
  • Is there an example that clearly shows the disaster of not implementing all these?
• Observe that cache coherence protocol is orthogonal
  • But such violations are rare
  • Does it make sense to invest so much time (for verification) and hardware (associative lookup logic in load queue)?
  • Many processors today relax the consistency model to get rid of complex hardware and achieve some extra performance at the cost of making program reasoning complex
  • P0: A=1; B=1; flag=1; P1: while (!flag); print A; print B;
  • SC is too restrictive; relaxing it does not always violate programmers' intuition