= Solution
A <store buffer> holds the <memory address> and value of a <store instruction> while the <memory cache> or backing <computer memory> completes the write. The <in-order pipeline> can continue after enqueueing the write, rather than waiting for a possibly long <memory access latency>. A full <store buffer> eventually causes a <pipeline stall>; buffering hides finite delays, not an indefinitely inadequate service rate.
Without a <memory management unit>, the comparison can use the actual <physical addresses>; there is no <address translation> or synonym problem to solve. Suppose `x` initially contains zero and these operations execute in order:
``
STORE [x], 7
LOAD r1, [x]
``
If the write is still in the <store buffer>, reading only <computer memory> could incorrectly return zero. The <load instruction> searches older buffered <store instructions> for an overlapping <memory address>. If the newest matching write covers the requested <bytes> and its data are ready, <store-to-load forwarding> returns seven directly. With several pending writes to `x`, the youngest older matching write wins. If the relevant data are not ready, the <load instruction> waits; partial overlaps require merging the covered <bytes> or conservatively waiting for the writes to drain.
A <load instruction> from an unrelated address `y` can bypass those buffered writes, subject to the architecture's <memory model>. \b[Buffer writes to overlap them with useful execution, but preserve each load's dependence on older writes to the same bytes.] Device accesses through <memory-mapped input-output> need their specified ordering and should not be treated as ordinary cacheable <computer memory>.
$$
\boxed{\text{Buffer stores, but forward or wait when a later load overlaps them.}}
$$
Back to article page
