summaryrefslogtreecommitdiffstats
path: root/cpu_supplement/intel_amd_x86.rst
diff options
context:
space:
mode:
authorChris Johns <chrisj@rtems.org>2016-10-07 11:13:16 +1300
committerChris Johns <chrisj@rtems.org>2016-10-07 11:13:16 +1300
commitf233256327e8a01a1236dbdd0f91701bc229936b (patch)
tree418c22a848fda4c88cbe08404a76b7a36b3cd3d3 /cpu_supplement/intel_amd_x86.rst
parente6fe68d51d51bebecb645369f7e0beec6b694a9a (diff)
downloadrtems-docs-f233256327e8a01a1236dbdd0f91701bc229936b.tar.bz2
Clean up the CPU Supplement.
Diffstat (limited to 'cpu_supplement/intel_amd_x86.rst')
-rw-r--r--cpu_supplement/intel_amd_x86.rst340
1 files changed, 155 insertions, 185 deletions
diff --git a/cpu_supplement/intel_amd_x86.rst b/cpu_supplement/intel_amd_x86.rst
index 0597f19..37ff569 100644
--- a/cpu_supplement/intel_amd_x86.rst
+++ b/cpu_supplement/intel_amd_x86.rst
@@ -1,15 +1,19 @@
.. comment SPDX-License-Identifier: CC-BY-SA-4.0
+.. COMMENT: COPYRIGHT (c) 1988-2002.
+.. COMMENT: On-Line Applications Research Corporation (OAR).
+.. COMMENT: All rights reserved.
+.. COMMENT: Jukka Pietarinen <jukka.pietarinen@mrf.fi>, 2008,
+.. COMMENT: Micro-Research Finland Oy
+
Intel/AMD x86 Specific Information
##################################
-This chapter discusses the Intel x86 architecture dependencies
-in this port of RTEMS. This family has multiple implementations
-from multiple vendors and suffers more from having evolved rather
-than being designed for growth.
+This chapter discusses the Intel x86 architecture dependencies in this port of
+RTEMS. This family has multiple implementations from multiple vendors and
+suffers more from having evolved rather than being designed for growth.
-For information on the i386 processor, refer to the
-following documents:
+For information on the i386 processor, refer to the following documents:
- *386 Programmer's Reference Manual, Intel, Order No. 230985-002*.
@@ -23,19 +27,17 @@ following documents:
CPU Model Dependent Features
============================
-This section presents the set of features which vary
-across i386 implementations and are of importance to RTEMS.
-The set of CPU model feature macros are defined in the file``cpukit/score/cpu/i386/i386.h`` based upon the particular CPU
-model specified on the compilation command line.
+This section presents the set of features which vary across i386
+implementations and are of importance to RTEMS. The set of CPU model feature
+macros are defined in the :file:`cpukit/score/cpu/i386/i386.h` based upon the
+particular CPU model specified on the compilation command line.
bswap Instruction
-----------------
-The macro ``I386_HAS_BSWAP`` is set to 1 to indicate that
-this CPU model has the ``bswap`` instruction which
-endian swaps a thirty-two bit quantity. This instruction
-appears to be present in all CPU models
-i486's and above.
+The macro ``I386_HAS_BSWAP`` is set to 1 to indicate that this CPU model has
+the ``bswap`` instruction which endian swaps a thirty-two bit quantity. This
+instruction appears to be present in all CPU models i486's and above.
Calling Conventions
===================
@@ -43,43 +45,40 @@ Calling Conventions
Processor Background
--------------------
-The i386 architecture supports a simple yet effective
-call and return mechanism. A subroutine is invoked via the call
-(``call``) instruction. This instruction pushes the return address
-on the stack. The return from subroutine (``ret``) instruction pops
-the return address off the current stack and transfers control
-to that instruction. It is is important to note that the i386
-call and return mechanism does not automatically save or restore
-any registers. It is the responsibility of the high-level
-language compiler to define the register preservation and usage
-convention.
+The i386 architecture supports a simple yet effective call and return
+mechanism. A subroutine is invoked via the call (``call``) instruction. This
+instruction pushes the return address on the stack. The return from subroutine
+(``ret``) instruction pops the return address off the current stack and
+transfers control to that instruction. It is is important to note that the
+i386 call and return mechanism does not automatically save or restore any
+registers. It is the responsibility of the high-level language compiler to
+define the register preservation and usage convention.
Calling Mechanism
-----------------
-All RTEMS directives are invoked using a call instruction and return to
-the user application via the ret instruction.
+All RTEMS directives are invoked using a call instruction and return to the
+user application via the ret instruction.
Register Usage
--------------
-As discussed above, the call instruction does not automatically save
-any registers. RTEMS uses the registers EAX, ECX, and EDX as scratch
-registers. These registers are not preserved by RTEMS directives
-therefore, the contents of these registers should not be assumed upon
-return from any RTEMS directive.
+As discussed above, the call instruction does not automatically save any
+registers. RTEMS uses the registers EAX, ECX, and EDX as scratch registers.
+These registers are not preserved by RTEMS directives therefore, the contents
+of these registers should not be assumed upon return from any RTEMS directive.
Parameter Passing
-----------------
-RTEMS assumes that arguments are placed on the
-current stack before the directive is invoked via the call
-instruction. The first argument is assumed to be closest to the
-return address on the stack. This means that the first argument
-of the C calling sequence is pushed last. The following
-pseudo-code illustrates the typical sequence used to call a
-RTEMS directive with three (3) arguments:
-.. code:: c
+RTEMS assumes that arguments are placed on the current stack before the
+directive is invoked via the call instruction. The first argument is assumed
+to be closest to the return address on the stack. This means that the first
+argument of the C calling sequence is pushed last. The following pseudo-code
+illustrates the typical sequence used to call a RTEMS directive with three (3)
+arguments:
+
+.. code-block:: c
push third argument
push second argument
@@ -87,11 +86,10 @@ RTEMS directive with three (3) arguments:
invoke directive
remove arguments from the stack
-The arguments to RTEMS are typically pushed onto the
-stack using a push instruction. These arguments must be removed
-from the stack after control is returned to the caller. This
-removal is typically accomplished by adding the size of the
-argument list in bytes to the stack pointer.
+The arguments to RTEMS are typically pushed onto the stack using a push
+instruction. These arguments must be removed from the stack after control is
+returned to the caller. This removal is typically accomplished by adding the
+size of the argument list in bytes to the stack pointer.
Memory Model
============
@@ -99,54 +97,47 @@ Memory Model
Flat Memory Model
-----------------
-RTEMS supports the i386 protected mode, flat memory
-model with paging disabled. In this mode, the i386
-automatically converts every address from a logical to a
-physical address each time it is used. The i386 uses
-information provided in the segment registers and the Global
-Descriptor Table to convert these addresses. RTEMS assumes the
-existence of the following segments:
+RTEMS supports the i386 protected mode, flat memory model with paging disabled.
+In this mode, the i386 automatically converts every address from a logical to a
+physical address each time it is used. The i386 uses information provided in
+the segment registers and the Global Descriptor Table to convert these
+addresses. RTEMS assumes the existence of the following segments:
-- a single code segment at protection level (0) which
- contains all application and executive code.
+- a single code segment at protection level (0) which contains all application
+ and executive code.
-- a single data segment at protection level zero (0) which
- contains all application and executive data.
+- a single data segment at protection level zero (0) which contains all
+ application and executive data.
-The i386 segment registers and associated selectors
-must be initialized when the initialize_executive directive is
-invoked. RTEMS treats the segment registers as system registers
-and does not modify or context switch them.
+The i386 segment registers and associated selectors must be initialized when
+the initialize_executive directive is invoked. RTEMS treats the segment
+registers as system registers and does not modify or context switch them.
-This i386 memory model supports a flat 32-bit address
-space with addresses ranging from 0x00000000 to 0xFFFFFFFF (4
-gigabytes). Each address is represented by a 32-bit value and
-is byte addressable. The address may be used to reference a
-single byte, half-word (2-bytes), or word (4 bytes).
+This i386 memory model supports a flat 32-bit address space with addresses
+ranging from 0x00000000 to 0xFFFFFFFF (4 gigabytes). Each address is
+represented by a 32-bit value and is byte addressable. The address may be used
+to reference a single byte, half-word (2-bytes), or word (4 bytes).
Interrupt Processing
====================
-Although RTEMS hides many of the processor
-dependent details of interrupt processing, it is important to
-understand how the RTEMS interrupt manager is mapped onto the
-processor's unique architecture. Discussed in this chapter are
-the the processor's response and control mechanisms as they
-pertain to RTEMS.
+Although RTEMS hides many of the processor dependent details of interrupt
+processing, it is important to understand how the RTEMS interrupt manager is
+mapped onto the processor's unique architecture. Discussed in this chapter are
+the the processor's response and control mechanisms as they pertain to RTEMS.
Vectoring of Interrupt Handler
------------------------------
-Although the i386 supports multiple privilege levels,
-RTEMS and all user software executes at privilege level 0. This
-decision was made by the RTEMS designers to enhance
-compatibility with processors which do not provide sophisticated
-protection facilities like those of the i386. This decision
-greatly simplifies the discussion of i386 processing, as one
-need only consider interrupts without privilege transitions.
+Although the i386 supports multiple privilege levels, RTEMS and all user
+software executes at privilege level 0. This decision was made by the RTEMS
+designers to enhance compatibility with processors which do not provide
+sophisticated protection facilities like those of the i386. This decision
+greatly simplifies the discussion of i386 processing, as one need only consider
+interrupts without privilege transitions.
-Upon receipt of an interrupt the i386 automatically
-performs the following actions:
+Upon receipt of an interrupt the i386 automatically performs the following
+actions:
- pushes the EFLAGS register
@@ -154,15 +145,13 @@ performs the following actions:
- vectors to the interrupt service routine (ISR).
-A nested interrupt is processed similarly by the
-i386.
+A nested interrupt is processed similarly by the i386.
Interrupt Stack Frame
---------------------
-The structure of the Interrupt Stack Frame for the
-i386 which is placed on the interrupt stack by the processor in
-response to an interrupt is as follows:
+The structure of the Interrupt Stack Frame for the i386 which is placed on the
+interrupt stack by the processor in response to an interrupt is as follows:
+----------------------+-------+
| Old EFLAGS Register | ESP+8 |
@@ -176,37 +165,33 @@ response to an interrupt is as follows:
Interrupt Levels
----------------
-Although RTEMS supports 256 interrupt levels, the
-i386 only supports two - enabled and disabled. Interrupts are
-enabled when the interrupt-enable flag (IF) in the extended
-flags (EFLAGS) is set. Conversely, interrupt processing is
-inhibited when the IF is cleared. During a non-maskable
-interrupt, all other interrupts, including other non-maskable
-ones, are inhibited.
+Although RTEMS supports 256 interrupt levels, the i386 only supports two -
+enabled and disabled. Interrupts are enabled when the interrupt-enable flag
+(IF) in the extended flags (EFLAGS) is set. Conversely, interrupt processing
+is inhibited when the IF is cleared. During a non-maskable interrupt, all
+other interrupts, including other non-maskable ones, are inhibited.
RTEMS interrupt levels 0 and 1 such that level zero
-(0) indicates that interrupts are fully enabled and level one
-that interrupts are disabled. All other RTEMS interrupt levels
-are undefined and their behavior is unpredictable.
+(0) indicates that interrupts are fully enabled and level one that interrupts
+are disabled. All other RTEMS interrupt levels are undefined and their
+behavior is unpredictable.
Interrupt Stack
---------------
-The i386 family does not support a dedicated hardware
-interrupt stack. On this processor, RTEMS allocates and manages
-a dedicated interrupt stack. As part of vectoring a non-nested
-interrupt service routine, RTEMS switches from the stack of the
-interrupted task to a dedicated interrupt stack. When a
-non-nested interrupt returns, RTEMS switches back to the stack
-of the interrupted stack. The current stack pointer is not
-altered by RTEMS on nested interrupt.
+The i386 family does not support a dedicated hardware interrupt stack. On this
+processor, RTEMS allocates and manages a dedicated interrupt stack. As part of
+vectoring a non-nested interrupt service routine, RTEMS switches from the stack
+of the interrupted task to a dedicated interrupt stack. When a non-nested
+interrupt returns, RTEMS switches back to the stack of the interrupted stack.
+The current stack pointer is not altered by RTEMS on nested interrupt.
Default Fatal Error Processing
==============================
The default fatal error handler for this architecture disables processor
-interrupts, places the error code in EAX, and executes a HLT instruction
-to halt the processor.
+interrupts, places the error code in EAX, and executes a HLT instruction to
+halt the processor.
Symmetric Multiprocessing
=========================
@@ -224,36 +209,34 @@ Board Support Packages
System Reset
------------
-An RTEMS based application is initiated when the i386 processor is reset.
-When the i386 is reset,
+An RTEMS based application is initiated when the i386 processor is reset. When
+the i386 is reset,
-- The EAX register is set to indicate the results of the processor's
- power-up self test. If the self-test was not executed, the contents of
- this register are undefined. Otherwise, a non-zero value indicates the
- processor is faulty and a zero value indicates a successful self-test.
+- The EAX register is set to indicate the results of the processor's power-up
+ self test. If the self-test was not executed, the contents of this register
+ are undefined. Otherwise, a non-zero value indicates the processor is faulty
+ and a zero value indicates a successful self-test.
-- The DX register holds a component identifier and revision level. DH
- contains 3 to indicate an i386 component and DL contains a unique revision
- level indicator.
+- The DX register holds a component identifier and revision level. DH contains
+ 3 to indicate an i386 component and DL contains a unique revision level
+ indicator.
-- Control register zero (CR0) is set such that the processor is in real
- mode with paging disabled. Other portions of CR0 are used to indicate the
+- Control register zero (CR0) is set such that the processor is in real mode
+ with paging disabled. Other portions of CR0 are used to indicate the
presence of a numeric coprocessor.
-- All bits in the extended flags register (EFLAG) which are not
- permanently set are cleared. This inhibits all maskable interrupts.
+- All bits in the extended flags register (EFLAG) which are not permanently set
+ are cleared. This inhibits all maskable interrupts.
-- The Interrupt Descriptor Register (IDTR) is set to point at address
- zero.
+- The Interrupt Descriptor Register (IDTR) is set to point at address zero.
- All segment registers are set to zero.
-- The instruction pointer is set to 0x0000FFF0. The first instruction
- executed after a reset is actually at 0xFFFFFFF0 because the i386 asserts
- the upper twelve address until the first intersegment (FAR) JMP or CALL
- instruction. When a JMP or CALL is executed, the upper twelve address
- lines are lowered and the processor begins executing in the first megabyte
- of memory.
+- The instruction pointer is set to 0x0000FFF0. The first instruction executed
+ after a reset is actually at 0xFFFFFFF0 because the i386 asserts the upper
+ twelve address until the first intersegment (FAR) JMP or CALL instruction.
+ When a JMP or CALL is executed, the upper twelve address lines are lowered
+ and the processor begins executing in the first megabyte of memory.
Typically, an intersegment JMP to the application's initialization code is
placed at address 0xFFFFFFF0.
@@ -261,62 +244,49 @@ placed at address 0xFFFFFFF0.
Processor Initialization
------------------------
-This initialization code is responsible for initializing all data
-structures required by the i386 in protected mode and for actually entering
-protected mode. The i386 must be placed in protected mode and the segment
-registers and associated selectors must be initialized before the
-initialize_executive directive is invoked.
-
-The initialization code is responsible for initializing the Global
-Descriptor Table such that the i386 is in the thirty-two bit flat memory
-model with paging disabled. In this mode, the i386 automatically converts
-every address from a logical to a physical address each time it is used.
-For more information on the memory model used by RTEMS, please refer to the
-Memory Model chapter in this document.
-
-Since the processor is in real mode upon reset, the processor must be
-switched to protected mode before RTEMS can execute. Before switching to
-protected mode, at least one descriptor table and two descriptors must be
-created. Descriptors are needed for a code segment and a data segment. (
-This will give you the flat memory model.) The stack can be placed in a
-normal read/write data segment, so no descriptor for the stack is needed.
-Before the GDT can be used, the base address and limit must be loaded into
-the GDTR register using an LGDT instruction.
-
-If the hardware allows an NMI to be generated, you need to create the IDT
-and a gate for the NMI interrupt handler. Before the IDT can be used, the
-base address and limit for the idt must be loaded into the IDTR register
-using an LIDT instruction.
-
-Protected mode is entered by setting thye PE bit in the CR0 register.
-Either a LMSW or MOV CR0 instruction may be used to set this bit. Because
-the processor overlaps the interpretation of several instructions, it is
-necessary to discard the instructions from the read-ahead cache. A JMP
-instruction immediately after the LMSW changes the flow and empties the
-processor if intructions which have been pre-fetched and/or decoded. At
-this point, the processor is in protected mode and begins to perform
-protected mode application initialization.
-
-If the application requires that the IDTR be some value besides zero, then
-it should set it to the required value at this point. All tasks share the
-same i386 IDTR value. Because interrupts are enabled automatically by
-RTEMS as part of the initialize_executive directive, the IDTR MUST be set
-properly before this directive is invoked to insure correct interrupt
-vectoring. If processor caching is to be utilized, then it should be
-enabled during the reset application initialization code. The reset code
-which is executed before the call to initialize_executive has the following
-requirements:
-
-For more information regarding the i386 data structures and their
-contents, refer to Intel's 386 Programmer's Reference Manual.
-
-.. COMMENT: COPYRIGHT (c) 1988-2002.
-
-.. COMMENT: On-Line Applications Research Corporation (OAR).
-
-.. COMMENT: All rights reserved.
-
-.. COMMENT: Jukka Pietarinen <jukka.pietarinen@mrf.fi>, 2008,
-
-.. COMMENT: Micro-Research Finland Oy
-
+This initialization code is responsible for initializing all data structures
+required by the i386 in protected mode and for actually entering protected
+mode. The i386 must be placed in protected mode and the segment registers and
+associated selectors must be initialized before the initialize_executive
+directive is invoked.
+
+The initialization code is responsible for initializing the Global Descriptor
+Table such that the i386 is in the thirty-two bit flat memory model with paging
+disabled. In this mode, the i386 automatically converts every address from a
+logical to a physical address each time it is used. For more information on
+the memory model used by RTEMS, please refer to the Memory Model chapter in
+this document.
+
+Since the processor is in real mode upon reset, the processor must be switched
+to protected mode before RTEMS can execute. Before switching to protected
+mode, at least one descriptor table and two descriptors must be created.
+Descriptors are needed for a code segment and a data segment. ( This will give
+you the flat memory model.) The stack can be placed in a normal read/write
+data segment, so no descriptor for the stack is needed. Before the GDT can be
+used, the base address and limit must be loaded into the GDTR register using an
+LGDT instruction.
+
+If the hardware allows an NMI to be generated, you need to create the IDT and a
+gate for the NMI interrupt handler. Before the IDT can be used, the base
+address and limit for the idt must be loaded into the IDTR register using an
+LIDT instruction.
+
+Protected mode is entered by setting thye PE bit in the CR0 register. Either a
+LMSW or MOV CR0 instruction may be used to set this bit. Because the processor
+overlaps the interpretation of several instructions, it is necessary to discard
+the instructions from the read-ahead cache. A JMP instruction immediately after
+the LMSW changes the flow and empties the processor if intructions which have
+been pre-fetched and/or decoded. At this point, the processor is in protected
+mode and begins to perform protected mode application initialization.
+
+If the application requires that the IDTR be some value besides zero, then it
+should set it to the required value at this point. All tasks share the same
+i386 IDTR value. Because interrupts are enabled automatically by RTEMS as part
+of the initialize_executive directive, the IDTR MUST be set properly before
+this directive is invoked to insure correct interrupt vectoring. If processor
+caching is to be utilized, then it should be enabled during the reset
+application initialization code. The reset code which is executed before the
+call to initialize_executive has the following requirements:
+
+For more information regarding the i386 data structures and their contents,
+refer to Intel's 386 Programmer's Reference Manual.