This preview shows page 1. Sign up to view the full content.
Unformatted text preview: use the following steps: — Use a locked operation to modify the access-rights byte to indicate that the segment descriptor is not-present, and specify a value for the type field that indicates that the descriptor is being updated. — Update the fields of the segment descriptor. (This operation may require several memory accesses; therefore, locked operations cannot be used.) • 7-3 MULTIPLE-PROCESSOR MANAGEMENT — Use a locked operation to modify the access-rights byte to indicate that the segment descriptor is valid and present. Note that the Intel386™ processor always updates the accessed flag in the segment descriptor, whether it is clear or not. The P6 family, Pentium®, and Intel486™ processors only update this flag if it is not already set. • • When updating page-directory and page-table entries. When updating page-directory and page-table entries, the processor uses locked cycles to set the accessed and dirty flag in the page-directory and page-table entries. Acknowledging interrupts. After an interrupt request, an interrupt controller may use the data bus to send the interrupt vector for the interrupt to the processor. The processor follows the LOCK semantics during this time to ensure that no other data appears on the data bus when the interrupt vector is being transmitted. SOFTWARE CONTROLLED BUS LOCKING 184.108.40.206. To explicitly force the LOCK semantics, software can use the LOCK prefix with the following instructions when they are used to modify a memory location. An invalid-opcode exception (#UD) is generated when the LOCK prefix is used with any other instruction or when no write operation is made to memory (that is, when the destination operand is in a register). • • • • • The bit test and modify instructions (BTS, BTR, and BTC). The exchange instructions (XADD, CMPXCHG, and CMPXCHG8B). The LOCK prefix is automatically assumed for XCHG instruction. The following single-operand arithmetic and logical instructions: INC, DEC, NOT, and NEG. The following two-operand arithmetic and logical instructions: ADD, ADC, SUB, SBB, AND, OR, and XOR. A locked instruction is guaranteed to lock only the area of memory defined by the destination operand, but may be interpreted by the system as a lock for a larger memory area. Software should access semaphores (shared memory used for signaling between multiple processors) using identical addresses and operand lengths. For example, if one processor accesses a semaphore using a word access, other processors should not access the semaphore using a byte access. The integrity of a bus lock is not affected by the alignment of the memory field. The LOCK semantics are followed for as many bus cycles as necessary to update the entire operand. However, it is recommend that locked accesses be aligned on their natural boundaries for better system performance: • • •
7-4 Any boundary for an 8-bit access (locked or otherwise). 16-bit boundary for locked word accesses. 32-bit boundary for locked doubleword access. MULTIPLE-PROCESSOR MANAGEMENT • 64-bit boundary for locked quadword access. Locked operations are atomic with respect to all other memory operations and all externally visible events. Only instruction fetch and page table accesses can pass locked instructions. Locked instructions can be used to synchronize data written by one processor and read by another processor. For the P6 family processors, locked operations serialize all outstanding load and store operations (that is, wait for them to complete). Locked instructions should not be used to insure that data written can be fetched as instructions.
NOTE The locked instructions for the current versions of the Intel486™, Pentium®, and P6 family processors will allow data written to be fetched as instructions. However, Intel recommends that developers who require the use of selfmodifying code use a different synchronizing mechanism, described in the following sections. 7.1.3. Handling Self- and Cross-Modifying Code The act of a processor writing data into a currently executing code segment with the intent of executing that data as code is called self-modifying code. Intel Architecture processors exhibit model-specific behavior when executing self-modified code, depending upon how far ahead of the current execution pointer the code has been modified. As processor architectures become more complex and start to speculatively execute code ahead of the retirement point (as in the P6 family processors), the rules regarding which code should execute, pre- or post-modification, become blurred. To write self-modifying code and ensure that it is compliant with current and future Intel Architectures one of the following two coding options should be chosen.
(* OPTION 1 *) Store modified code (as data) into code segment; Jump to new code or an intermediate location; Execute new code; (* OPTION 2 *) Store modified code (as data) into code segment; Execute a serializing instruction; (* For example, CPUID instruction *) Execute new code; (The use of one of these options is not required for programs intended to run on the Pentium® or Intel486™ processors, but are r...
View Full Document
This note was uploaded on 06/07/2013 for the course ECE 1234 taught by Professor Kwhon during the Spring '10 term at Berkeley.
- Spring '10