AMCC Proprietary 55
Revision 1.02 - September 10, 2007
PPC405 Processor
Preliminary User’s Manual
Consider also the above code sequence, with the rfi instruction replaced by an sc instruction used to initialize the
CTR with the appropriate value for the bctr to branch to, upon return from the system call. The
sc handler returns
to the instruction following the
sc, which can’t be a branch hang. Instead, software could put a mtctr just before
the
sc to load a non-sensitive address into the CTR. This address will be used as the prediction address before the
sc executes. An alternative would be to put a mfctr or mtctr between the sc and the bctr; the mtctr prevents the
fetcher from speculatively accessing the address contained in the CTR before initialization.
2.8.2.2 Fetching Past tw or twi Instructions
The interrupt-causing instructions,
tw and twi, do not require the special handling described in Fetching Past an
Interrupt-Causing or Interrupt-Returning Instruction on page 54. These instructions are typically used by
debuggers, which implement software breakpoints by substituting a trap instruction for the instruction originally at
the breakpoint address. In a code sequence mtlr followed by
blr (or mtctr followed by bctr), replacement of
mtlr/mtctr by tw or twi leaves the LR/CTR uninitialized. It would be inappropriate to fetch from the blr/bctr target
address. This situation is common, and the fetcher is designed to prevent the problem.
2.8.2.3 Fetching Past an Unconditional Branch
When an unconditional branch is in DCD in the instruction queue, the fetcher recognizes that the sequential
instructions following the branch are unnecessary. These sequential addresses are not accessed. Addresses at
the branch target are accessed instead.
Therefore, placing an unconditional branch just before the start of a sensitive address space (for example, at the
“end” of a memory area that borders an I/O device) guarantees that addresses in the sensitive area will not be
speculatively fetched.
2.8.2.4 Suggested Locations of Memory-Mapped Hardware
The preferred method of protecting memory-mapped hardware from inadvertent access is to use address
translation, with hardware isolated to guarded pages (the G storage attribute in the associated TLB entry is set
to 1.) The pages can be as small as 1KB. Code should never be stored in such pages.
If address translation is disabled, the preferred protection method is to isolate memory-mapped hardware into
regions guarded using the SGR. Code should never be stored in such regions. The disadvantage of this method,
compared to the preferred method, is that each region guarded by the SGR consumes 128MB of the address
space.
Table 2-10 shows two address regions of the PPC405. Suppose a system designer can map all I/O devices and all
ROM and SRAM devices into any location in either region. The choices made by the designer can prevent
speculative accesses to the memory-mapped I/O devices.
A simple way to avoid the problem of speculative reads to peripherals is to map all storage containing code into
Region 2, and all I/O devices into Region 1. Thus, accesses to Region 2 would only be for code and program data.
Speculative fetches occurring in Region 2 would never access addresses in Region 1. Note that this hardware
organization eliminates the need to use of the G storage attribute to protect Region 1. However, Region 1 could be
set as guarded with no performance penalty, because there is no code to execute or variable data to access in
Region 1.
Table 2-10. Example Memory Mapping
0x7800 0000 – 0x7FFF FFFF (SGR bit 15) 128MB Region 2
0x7000 0000 – 0x77FF FFFF (SGR bit 14) 128MB Region 1
To Next Page
Loading...