Intel ITANIUM ARCHITECTURE - SOFTWARE DEVELOPERS MANUAL VOLUME 1 REV 2.3 Manual page 781

2.5.2 Cross-modifying Code
Consider a multi-threaded program for a multiprocessor system that dynamically
updates some procedure that any processor in the system may execute. The program
maintains several disjoint buffers to hold the new code and requires a processor to
execute an IP-relative branch instruction at some address x to reach the code. In this
scenario, the program updates the procedure by emitting the new code into a different
buffer and then patching the branch at address x to target this new buffer. By carefully
writing the update code, software can ensure that any processor in the system sees
either:
• The original branch at address x that targets the original code in the old buffer
along with the original code, or
• The new branch at address x that targets the new code in the new buffer along with
the new code.
The code in
sequence that implements the cross-modifying code for this example.
Figure 2-9.
patch:
st
fc.i
sync.i ;;
// Update the target of the branch that jumps to the updated code.
// This branch MUST be ip-relative. Before executing the following
// store, the branch jumps to somewhere other than "new_code".
//
st.rel [x] = "branch <new_code>"
// If it is desired to propagate "branch <new_code>" to both
// the local processor and remote processor now, the following
// code is also necessary:
//
fc.i
sync.i ;;
mf ;;
To reach the new code at new_code, the processor executes the branch instruction at x.
Initially, this branch jumps to an address other than new_code.
Note: The programmer needs to ensure that the branch to new_code is updated atom-
ically. If an 8-byte store is used to update the branch, then the programmer
needs to ensure that the branch to new_code is either in the first or last slot of
the bundle.
The release store ensures a processor cannot see the new branch at address x and the
original code at address new_code. That is, if a processor encounters "branch
<new_code>" at address x, then the processor's instruction cache must be coherent
with the code image updates applied before the release store that updates the branch.
If remote processors may see either the old or new code sequence, the final three
instructions in
code image updates at some point in the future. In the meantime, they continue to
execute the old code.
Volume 2, Part 2: MP Coherence and Synchronization
Figure 2-9 illustrates an optimized Itanium architecture-based code
Supporting Cross-modifying Code without Explicit Serialization
[new_code] = new_inst // write new instruction
new_code ;;
x ;;
Figure 2-9 are not necessary. In this case, the remote processors see the
// flush new instruction
// sync i stream with store
// flush branch
// sync i stream with store
// fence
2:533