March 2002 Release
467
Virtex-II Pro™ Platform FPGA Documentation
1-800-255-7778
Software Management of Cache Coherency
R
li
r
3,256
! Number of congruence classes in cache.
mtctr r
3
loop:
dcbz
0,
r
1
! Flush one way of the cache set.
dcbz r
2,
r
1
! Flush the other way of the cache set.
dccci
0,
r
1
! Invalidate the cache set.
addi r
1,
r
1,32
! Point to the next cacheline.
bdnz
loop
! Continue until all sets are flushed.
sync
! Ensure cache data has been written.
<Re-enable interrupts>
Interrupts are disabled during the flush procedure to prevent possible system-memory
corruption occurring due to an unexpected system-memory access. These problems can
arise if an interrupt occurs after a
dcbz
establishes a new cacheline but before the
dccci
invalidates that line. Executing the interrupt handler could cause a flush of the new line
due to normal line replacement. This could corrupt system-memory or cause invalid
memory accesses. Disabling interrupts eliminates the potential for unexpected cache
activity.
Self-Modifying Code
Software that updates executable-memory locations is known as
self-modifying code
. If self-
modifying code operates on cacheable-memory locations, cache-control instructions must
be executed to maintain coherency between the instruction cache, system memory, and the
data cache. Data-cache coherency is an issue because the instructions are treated as data
when they are modified by other instructions.
Software that relocates executable code from one cacheable-memory location to another
requires the same coherency treatment as self-modifying code. Although instructions are
not changed, they are treated as data by the program that moves them, and can therefore
be cached by the data cache.
The following code sequence can be used to enforce coherency between system memory
and both the instruction and data caches. In this example, instructions are moved
individually from one memory location to another while caching is enabled. Cache
coherency is maintained throughout the process. Performance can be improved if software
prohibits execution of the instructions while they are moved so that the caches are flushed
and invalidated outside the loop.
!
r
1 = Instruction source address (word aligned).
!
r
2 = Instruction target address (word aligned).
!
r
3 = Number of instructions to move.
addi r
1,
r
1,-4
! Initialize for use of
lwzu
and
stwu
addi r
2,
r
2,-4
mtctrr
3
loop:
lwzu r
4,4(
r
1)
! Read source instruction.
stwu r
4,4(
r
2)
! Write target instruction.
dcbf
0,
r
2
! Remove target instruction from data cache.
icbi
0,
r
2
! Remove target instruction from instruction cache.
bdnz
loop
! Repeat until all instructions are moved.
sync
! Synchronize execution.
isync
! Synchronize context.
Coherency of self-modifying code can be maintained in an similar fashion. Instead of
moving an instruction from one location to another, the source and target addresses are
identical. A modifying instruction (or sequence of instructions) is inserted between the
instruction load and instruction store. Below is a simple assembler-code sequence that can
be used to maintain cache coherency during self-modifying code operations.
