On Thu, 2014-03-20 at 19:47 +0800, Kevin Hao wrote: > OK, so the intention of 'twi, isync' following the load is not to order the > following storage access, but order the following delay loop instructions, > right? But according to the e6500 manual, the instructions complete in order. > The following is the definition of 'complete': > Complete—An instruction is eligible to complete after it finishes executing > and makes its results available for subsequent instructions. Instructions > must complete in order from the bottom two entries of the > completion queue (CQ). The completion unit coordinates how instructions > (which > may have executed out of order) affect architected registers to ensure the > appearance of serial execution. This guarantees that the completed > instruction > and all previous instructions can cause no exceptions. An instruction > completes > when it is retired, that is, deleted from the CQ. > > So the following delay loop instructions should never complete before the > complete of the load instruction.
We don't want the delay loop instructions to *start* until the load has completed. Completion of the loop only matters when ordering the loop versus post-loop actions (and again, there we'd want the loop to complete before subsequent actions start). > > > > > So if we want to order all the storage access as well > > > > > as execution synchronization, we should choose sync here. > > > > > > > > Do we need execution synchronization or context synchronization? > > > > > > There is no context-altering instruction here, so I think an execution > > > synchronizing instruction should be enough here. > > > > Is the ISA ever explicit about what constitutes "context"? > > The following is the definition of context-altering instruction: > An instruction that alters the context in which data > addresses or instruction addresses are interpreted, or > in which instructions are executed or data accesses are > performed, is called a context-altering instruction. > > So the context should be: > - in which data addresses or instruction addresses are interpreted > - in which instructions are executed > - in which data accesses are performed By that definition, a store to CCSR could easily change the context in which data accesses are performed, by changing a mapping. But still, nothing in the above defines "context" -- or rather, it does so circularly. While it makes intuitive sense that it would be limited to context that lives within the core, rather than the rest of the system, I don't think the ISA generally distinguishes between the two. -Scott _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
