source: rtems-docs/cpu-supplement/intel_amd_x86.rst @ 67195aa

5
Last change on this file since 67195aa was 44c9e33, checked in by Sebastian Huber <sebastian.huber@…>, on 06/12/17 at 09:09:06

cpu-supplement: Update TLS support status

Close #2468.

  • Property mode set to 100644
File size: 12.0 KB
Line 
1.. comment SPDX-License-Identifier: CC-BY-SA-4.0
2
3.. COMMENT: COPYRIGHT (c) 1988-2002.
4.. COMMENT: On-Line Applications Research Corporation (OAR).
5.. COMMENT: All rights reserved.
6.. COMMENT: Jukka Pietarinen <jukka.pietarinen@mrf.fi>, 2008,
7.. COMMENT: Micro-Research Finland Oy
8
9Intel/AMD x86 Specific Information
10**********************************
11
12This chapter discusses the Intel x86 architecture dependencies in this port of
13RTEMS.  This family has multiple implementations from multiple vendors and
14suffers more from having evolved rather than being designed for growth.
15
16For information on the i386 processor, refer to the following documents:
17
18- *386 Programmer's Reference Manual, Intel, Order No.  230985-002*.
19
20- *386 Microprocessor Hardware Reference Manual, Intel,
21  Order No. 231732-003*.
22
23- *80386 System Software Writer's Guide, Intel, Order No.  231499-001*.
24
25- *80387 Programmer's Reference Manual, Intel, Order No.  231917-001*.
26
27CPU Model Dependent Features
28============================
29
30This section presents the set of features which vary across i386
31implementations and are of importance to RTEMS.  The set of CPU model feature
32macros are defined in the :file:`cpukit/score/cpu/i386/i386.h` based upon the
33particular CPU model specified on the compilation command line.
34
35bswap Instruction
36-----------------
37
38The macro ``I386_HAS_BSWAP`` is set to 1 to indicate that this CPU model has
39the ``bswap`` instruction which endian swaps a thirty-two bit quantity.  This
40instruction appears to be present in all CPU models i486's and above.
41
42Calling Conventions
43===================
44
45Processor Background
46--------------------
47
48The i386 architecture supports a simple yet effective call and return
49mechanism.  A subroutine is invoked via the call (``call``) instruction.  This
50instruction pushes the return address on the stack.  The return from subroutine
51(``ret``) instruction pops the return address off the current stack and
52transfers control to that instruction.  It is is important to note that the
53i386 call and return mechanism does not automatically save or restore any
54registers.  It is the responsibility of the high-level language compiler to
55define the register preservation and usage convention.
56
57Calling Mechanism
58-----------------
59
60All RTEMS directives are invoked using a call instruction and return to the
61user application via the ret instruction.
62
63Register Usage
64--------------
65
66As discussed above, the call instruction does not automatically save any
67registers.  RTEMS uses the registers EAX, ECX, and EDX as scratch registers.
68These registers are not preserved by RTEMS directives therefore, the contents
69of these registers should not be assumed upon return from any RTEMS directive.
70
71Parameter Passing
72-----------------
73
74RTEMS assumes that arguments are placed on the current stack before the
75directive is invoked via the call instruction.  The first argument is assumed
76to be closest to the return address on the stack.  This means that the first
77argument of the C calling sequence is pushed last.  The following pseudo-code
78illustrates the typical sequence used to call a RTEMS directive with three (3)
79arguments:
80
81.. code-block:: c
82
83    push third argument
84    push second argument
85    push first argument
86    invoke directive
87    remove arguments from the stack
88
89The arguments to RTEMS are typically pushed onto the stack using a push
90instruction.  These arguments must be removed from the stack after control is
91returned to the caller.  This removal is typically accomplished by adding the
92size of the argument list in bytes to the stack pointer.
93
94Memory Model
95============
96
97Flat Memory Model
98-----------------
99
100RTEMS supports the i386 protected mode, flat memory model with paging disabled.
101In this mode, the i386 automatically converts every address from a logical to a
102physical address each time it is used.  The i386 uses information provided in
103the segment registers and the Global Descriptor Table to convert these
104addresses.  RTEMS assumes the existence of the following segments:
105
106- a single code segment at protection level (0) which contains all application
107  and executive code.
108
109- a single data segment at protection level zero (0) which contains all
110  application and executive data.
111
112The i386 segment registers and associated selectors must be initialized when
113the initialize_executive directive is invoked.  RTEMS treats the segment
114registers as system registers and does not modify or context switch them.
115
116This i386 memory model supports a flat 32-bit address space with addresses
117ranging from 0x00000000 to 0xFFFFFFFF (4 gigabytes).  Each address is
118represented by a 32-bit value and is byte addressable.  The address may be used
119to reference a single byte, half-word (2-bytes), or word (4 bytes).
120
121Interrupt Processing
122====================
123
124Although RTEMS hides many of the processor dependent details of interrupt
125processing, it is important to understand how the RTEMS interrupt manager is
126mapped onto the processor's unique architecture. Discussed in this chapter are
127the the processor's response and control mechanisms as they pertain to RTEMS.
128
129Vectoring of Interrupt Handler
130------------------------------
131
132Although the i386 supports multiple privilege levels, RTEMS and all user
133software executes at privilege level 0.  This decision was made by the RTEMS
134designers to enhance compatibility with processors which do not provide
135sophisticated protection facilities like those of the i386.  This decision
136greatly simplifies the discussion of i386 processing, as one need only consider
137interrupts without privilege transitions.
138
139Upon receipt of an interrupt the i386 automatically performs the following
140actions:
141
142- pushes the EFLAGS register
143
144- pushes the far address of the interrupted instruction
145
146- vectors to the interrupt service routine (ISR).
147
148A nested interrupt is processed similarly by the i386.
149
150Interrupt Stack Frame
151---------------------
152
153The structure of the Interrupt Stack Frame for the i386 which is placed on the
154interrupt stack by the processor in response to an interrupt is as follows:
155
156+----------------------+-------+
157| Old EFLAGS Register  | ESP+8 |
158+----------+-----------+-------+
159|   UNUSED |  Old CS   | ESP+4 |
160+----------+-----------+-------+
161|       Old EIP        | ESP   |
162+----------------------+-------+
163
164
165Interrupt Levels
166----------------
167
168Although RTEMS supports 256 interrupt levels, the i386 only supports two -
169enabled and disabled.  Interrupts are enabled when the interrupt-enable flag
170(IF) in the extended flags (EFLAGS) is set.  Conversely, interrupt processing
171is inhibited when the IF is cleared.  During a non-maskable interrupt, all
172other interrupts, including other non-maskable ones, are inhibited.
173
174RTEMS interrupt levels 0 and 1 such that level zero
175(0) indicates that interrupts are fully enabled and level one that interrupts
176are disabled.  All other RTEMS interrupt levels are undefined and their
177behavior is unpredictable.
178
179Interrupt Stack
180---------------
181
182The i386 family does not support a dedicated hardware interrupt stack.  On this
183processor, RTEMS allocates and manages a dedicated interrupt stack.  As part of
184vectoring a non-nested interrupt service routine, RTEMS switches from the stack
185of the interrupted task to a dedicated interrupt stack.  When a non-nested
186interrupt returns, RTEMS switches back to the stack of the interrupted stack.
187The current stack pointer is not altered by RTEMS on nested interrupt.
188
189Default Fatal Error Processing
190==============================
191
192The default fatal error handler for this architecture disables processor
193interrupts, places the error code in EAX, and executes a HLT instruction to
194halt the processor.
195
196Symmetric Multiprocessing
197=========================
198
199SMP is not supported.
200
201Thread-Local Storage
202====================
203
204Thread-local storage is supported.
205
206Board Support Packages
207======================
208
209System Reset
210------------
211
212An RTEMS based application is initiated when the i386 processor is reset.  When
213the i386 is reset,
214
215- The EAX register is set to indicate the results of the processor's power-up
216  self test.  If the self-test was not executed, the contents of this register
217  are undefined.  Otherwise, a non-zero value indicates the processor is faulty
218  and a zero value indicates a successful self-test.
219
220- The DX register holds a component identifier and revision level.  DH contains
221  3 to indicate an i386 component and DL contains a unique revision level
222  indicator.
223
224- Control register zero (CR0) is set such that the processor is in real mode
225  with paging disabled.  Other portions of CR0 are used to indicate the
226  presence of a numeric coprocessor.
227
228- All bits in the extended flags register (EFLAG) which are not permanently set
229  are cleared.  This inhibits all maskable interrupts.
230
231- The Interrupt Descriptor Register (IDTR) is set to point at address zero.
232
233- All segment registers are set to zero.
234
235- The instruction pointer is set to 0x0000FFF0.  The first instruction executed
236  after a reset is actually at 0xFFFFFFF0 because the i386 asserts the upper
237  twelve address until the first intersegment (FAR) JMP or CALL instruction.
238  When a JMP or CALL is executed, the upper twelve address lines are lowered
239  and the processor begins executing in the first megabyte of memory.
240
241Typically, an intersegment JMP to the application's initialization code is
242placed at address 0xFFFFFFF0.
243
244Processor Initialization
245------------------------
246
247This initialization code is responsible for initializing all data structures
248required by the i386 in protected mode and for actually entering protected
249mode.  The i386 must be placed in protected mode and the segment registers and
250associated selectors must be initialized before the initialize_executive
251directive is invoked.
252
253The initialization code is responsible for initializing the Global Descriptor
254Table such that the i386 is in the thirty-two bit flat memory model with paging
255disabled.  In this mode, the i386 automatically converts every address from a
256logical to a physical address each time it is used.  For more information on
257the memory model used by RTEMS, please refer to the Memory Model chapter in
258this document.
259
260Since the processor is in real mode upon reset, the processor must be switched
261to protected mode before RTEMS can execute.  Before switching to protected
262mode, at least one descriptor table and two descriptors must be created.
263Descriptors are needed for a code segment and a data segment. ( This will give
264you the flat memory model.)  The stack can be placed in a normal read/write
265data segment, so no descriptor for the stack is needed.  Before the GDT can be
266used, the base address and limit must be loaded into the GDTR register using an
267LGDT instruction.
268
269If the hardware allows an NMI to be generated, you need to create the IDT and a
270gate for the NMI interrupt handler.  Before the IDT can be used, the base
271address and limit for the idt must be loaded into the IDTR register using an
272LIDT instruction.
273
274Protected mode is entered by setting thye PE bit in the CR0 register.  Either a
275LMSW or MOV CR0 instruction may be used to set this bit. Because the processor
276overlaps the interpretation of several instructions, it is necessary to discard
277the instructions from the read-ahead cache. A JMP instruction immediately after
278the LMSW changes the flow and empties the processor if intructions which have
279been pre-fetched and/or decoded.  At this point, the processor is in protected
280mode and begins to perform protected mode application initialization.
281
282If the application requires that the IDTR be some value besides zero, then it
283should set it to the required value at this point.  All tasks share the same
284i386 IDTR value.  Because interrupts are enabled automatically by RTEMS as part
285of the initialize_executive directive, the IDTR MUST be set properly before
286this directive is invoked to insure correct interrupt vectoring.  If processor
287caching is to be utilized, then it should be enabled during the reset
288application initialization code.  The reset code which is executed before the
289call to initialize_executive has the following requirements:
290
291For more information regarding the i386 data structures and their contents,
292refer to Intel's 386 Programmer's Reference Manual.
Note: See TracBrowser for help on using the repository browser.