IBM PPC440X5 Computer Hardware User Manual


 
User’s Manual
PPC440x5 CPU Core Preliminary
Page 84 of 589
prgmodel.fm.
September 12, 2002
thought of as being context synchronizing with respect to the MSR[EE] bit, in that it guarantees that subse-
quent instructions execute (or are prevented from executing and an interrupt taken) according to the new
context of MSR[EE].
2.10.3 Storage Ordering and Synchronization
Storage synchronization enforces ordering between storage access instructions executed by the PPC440x5
core. There are two storage synchronizing instructions: msync and mbar. PowerPC Book-E architecture
defines different ordering requirements for these two instructions, but the PPC440x5 core implements them in
an identical fashion. Architecturally, msync is the “stronger” of the two, and is also execution synchronizing,
whereas mbar is not.
mbar acts as a “barrier” between all storage access instructions executed before the mbar and all those
executed after the mbar. That is, mbar ensures that all of the storage accesses initiated by instructions
before the mbar are performed with respect to the memory subsystem before any of the accesses initiated by
instructions after the mbar. However, mbar does not prevent subsequent instructions from executing (nor
even from completing) before the completion of the storage accesses initiated by instructions before the
mbar.
msync, on the other hand, does guarantee that all preceding storage accesses have actually been
performed with respect to the memory subsystem before the execution of any instruction after the msync.
Note that this requirement goes beyond the requirements of mere execution synchronization, in that execu-
tion synchronization doesn’t require the completion of preceding storage accesses.
The following two examples illustrate the distinctive use of mbar vs. msync.
stw Store data to an I/O device
msync Wait for store to actually complete
mtdcr Reconfigure the I/O device
In this example, the mtdcr is reconfiguring the I/O device in a manner which would cause the preceding store
instruction to fail, were the mtdcr to change the device before the completion of the store. Since mtdcr is not
a storage access instruction, the use of mbar instead of msync would not guarantee that the store is
performed before letting the mtdcr reconfigure the device. It only guarantees that subsequent storage
accesses are not performed to memory or any device before the earlier store.
Now consider this next example:
stb X Store data to an I/O device at address X, causing a status bit at address Y to be reset
mbar Guarantee preceding store is performed to the device before any subequent
storage accesses are performed
lbz Y Load status from the I/O device at address Y
Here, mbar is appropriate instead of msync, because all that is required is that the store to the I/O device
happens before the load does, but not that other instructions subsequent to the mbar won’t get executed
before the store.