1 | @c |
---|
2 | @c COPYRIGHT (c) 1988-2002. |
---|
3 | @c On-Line Applications Research Corporation (OAR). |
---|
4 | @c All rights reserved. |
---|
5 | |
---|
6 | @ifinfo |
---|
7 | @end ifinfo |
---|
8 | @chapter SPARC-64 Specific Information |
---|
9 | |
---|
10 | This document discusses the SPARC Version 9 (aka SPARC-64, SPARC64 or SPARC V9) |
---|
11 | architecture dependencies in this port of RTEMS. |
---|
12 | |
---|
13 | The SPARC V9 architecture leaves a lot of undefined implemenation dependencies |
---|
14 | which are defined by the processor models. Consult the specific CPU model |
---|
15 | section in this document for additional documents covering the implementation |
---|
16 | dependent architectural features. |
---|
17 | |
---|
18 | @subheading sun4u Specific Information |
---|
19 | sun4u is the subset of the SPARC V9 implementations comprising the UltraSPARC I |
---|
20 | through UltraSPARC IV processors. |
---|
21 | |
---|
22 | The following documents were used in developing the SPARC-64 sun4u port: |
---|
23 | @itemize @bullet |
---|
24 | @item UltraSPARC Userâs Manual |
---|
25 | (http://www.sun.com/microelectronics/manuals/ultrasparc/802-7220-02.pdf) |
---|
26 | @item UltraSPARC IIIi Processor (datasheets.chipdb.org/Sun/UltraSparc-IIIi.pdf) |
---|
27 | @end itemize |
---|
28 | |
---|
29 | @subheading sun4v Specific Information |
---|
30 | sun4v is the subset of the SPARC V9 implementations comprising the |
---|
31 | UltraSPARC T1 or T2 processors. |
---|
32 | |
---|
33 | The following documents were used in developing the SPARC-64 sun4v port: |
---|
34 | @itemize @bullet |
---|
35 | @item UltraSPARC Architecture 2005 Specification |
---|
36 | (http://opensparc-t1.sunsource.net/specs/UA2005-current-draft-P-EXT.pdf) |
---|
37 | @item UltraSPARC T1 supplement to UltraSPARC Architecture 2005 Specification |
---|
38 | (http://opensparc-t1.sunsource.net/specs/UST1-UASuppl-current-draft-P-EXT.pdf) |
---|
39 | @end itemize |
---|
40 | |
---|
41 | The defining feature that separates the sun4v architecture from its |
---|
42 | predecessor is the existence of a super-privileged hypervisor that |
---|
43 | is responsible for providing virtualized execution environments. The impact |
---|
44 | of the hypervisor on the real-time guarantees available with sun4v has not |
---|
45 | yet been determined. |
---|
46 | |
---|
47 | @c |
---|
48 | @c |
---|
49 | @c |
---|
50 | |
---|
51 | @section CPU Model Dependent Features |
---|
52 | |
---|
53 | @subsection CPU Model Feature Flags |
---|
54 | This section presents the set of features which vary across |
---|
55 | SPARC-64 implementations and |
---|
56 | are of importance to RTEMS. The set of CPU model feature macros |
---|
57 | are defined in the file |
---|
58 | cpukit/score/cpu/sparc64/sparc64.h based upon the particular |
---|
59 | CPU model defined on the compilation command line. |
---|
60 | |
---|
61 | @subsubsection CPU Model Name |
---|
62 | |
---|
63 | The macro CPU MODEL NAME is a string which designates |
---|
64 | the name of this CPU model. |
---|
65 | For example, for the UltraSPARC T1 SPARC V9 model, |
---|
66 | this macro is set to the string "sun4v". |
---|
67 | |
---|
68 | @subsubsection Floating Point Unit |
---|
69 | |
---|
70 | The macro SPARC_HAS_FPU is set to 1 to indicate that |
---|
71 | this CPU model has a hardware floating point unit and 0 |
---|
72 | otherwise. |
---|
73 | |
---|
74 | @subsubsection Number of Register Windows |
---|
75 | |
---|
76 | The macro SPARC_NUMBER_OF_REGISTER_WINDOWS is set to |
---|
77 | indicate the number of register window sets implemented by this |
---|
78 | CPU model. The SPARC architecture allows for a maximum of |
---|
79 | thirty-two register window sets although most implementations |
---|
80 | only include eight. |
---|
81 | |
---|
82 | @subsection CPU Model Implementation Notes |
---|
83 | |
---|
84 | This section describes the implemenation dependencies of the |
---|
85 | CPU Models sun4u and sun4v of the SPARC V9 architecture. |
---|
86 | |
---|
87 | @subsubsection sun4u Notes |
---|
88 | |
---|
89 | XXX |
---|
90 | |
---|
91 | @subsection sun4v Notes |
---|
92 | |
---|
93 | XXX |
---|
94 | |
---|
95 | @c |
---|
96 | @c COPYRIGHT (c) 1988-2002. |
---|
97 | @c On-Line Applications Research Corporation (OAR). |
---|
98 | @c All rights reserved. |
---|
99 | |
---|
100 | @section Calling Conventions |
---|
101 | |
---|
102 | Each high-level language compiler generates |
---|
103 | subroutine entry and exit code based upon a set of rules known |
---|
104 | as the compiler's calling convention. These rules address the |
---|
105 | following issues: |
---|
106 | |
---|
107 | @itemize @bullet |
---|
108 | @item register preservation and usage |
---|
109 | |
---|
110 | @item parameter passing |
---|
111 | |
---|
112 | @item call and return mechanism |
---|
113 | @end itemize |
---|
114 | |
---|
115 | A compiler's calling convention is of importance when |
---|
116 | interfacing to subroutines written in another language either |
---|
117 | assembly or high-level. Even when the high-level language and |
---|
118 | target processor are the same, different compilers may use |
---|
119 | different calling conventions. As a result, calling conventions |
---|
120 | are both processor and compiler dependent. |
---|
121 | |
---|
122 | The following document also provides some conventions on the |
---|
123 | global register usage in SPARC V9: |
---|
124 | http://developers.sun.com/solaris/articles/sparcv9abi.html |
---|
125 | |
---|
126 | @subsection Programming Model |
---|
127 | |
---|
128 | This section discusses the programming model for the |
---|
129 | SPARC architecture. |
---|
130 | |
---|
131 | @subsubsection Non-Floating Point Registers |
---|
132 | |
---|
133 | The SPARC architecture defines thirty-two |
---|
134 | non-floating point registers directly visible to the programmer. |
---|
135 | These are divided into four sets: |
---|
136 | |
---|
137 | @itemize @bullet |
---|
138 | @item input registers |
---|
139 | |
---|
140 | @item local registers |
---|
141 | |
---|
142 | @item output registers |
---|
143 | |
---|
144 | @item global registers |
---|
145 | @end itemize |
---|
146 | |
---|
147 | Each register is referred to by either two or three |
---|
148 | names in the SPARC reference manuals. First, the registers are |
---|
149 | referred to as r0 through r31 or with the alternate notation |
---|
150 | r[0] through r[31]. Second, each register is a member of one of |
---|
151 | the four sets listed above. Finally, some registers have an |
---|
152 | architecturally defined role in the programming model which |
---|
153 | provides an alternate name. The following table describes the |
---|
154 | mapping between the 32 registers and the register sets: |
---|
155 | |
---|
156 | @ifset use-ascii |
---|
157 | @example |
---|
158 | @group |
---|
159 | +-----------------+----------------+------------------+ |
---|
160 | | Register Number | Register Names | Description | |
---|
161 | +-----------------+----------------+------------------+ |
---|
162 | | 0 - 7 | g0 - g7 | Global Registers | |
---|
163 | +-----------------+----------------+------------------+ |
---|
164 | | 8 - 15 | o0 - o7 | Output Registers | |
---|
165 | +-----------------+----------------+------------------+ |
---|
166 | | 16 - 23 | l0 - l7 | Local Registers | |
---|
167 | +-----------------+----------------+------------------+ |
---|
168 | | 24 - 31 | i0 - i7 | Input Registers | |
---|
169 | +-----------------+----------------+------------------+ |
---|
170 | @end group |
---|
171 | @end example |
---|
172 | @end ifset |
---|
173 | |
---|
174 | @ifset use-tex |
---|
175 | @sp 1 |
---|
176 | @tex |
---|
177 | \centerline{\vbox{\offinterlineskip\halign{ |
---|
178 | \vrule\strut#& |
---|
179 | \hbox to 1.75in{\enskip\hfil#\hfil}& |
---|
180 | \vrule#& |
---|
181 | \hbox to 1.75in{\enskip\hfil#\hfil}& |
---|
182 | \vrule#& |
---|
183 | \hbox to 1.75in{\enskip\hfil#\hfil}& |
---|
184 | \vrule#\cr |
---|
185 | \noalign{\hrule} |
---|
186 | &\bf Register Number &&\bf Register Names&&\bf Description&\cr\noalign{\hrule} |
---|
187 | &0 - 7&&g0 - g7&&Global Registers&\cr\noalign{\hrule} |
---|
188 | &8 - 15&&o0 - o7&&Output Registers&\cr\noalign{\hrule} |
---|
189 | &16 - 23&&l0 - l7&&Local Registers&\cr\noalign{\hrule} |
---|
190 | &24 - 31&&i0 - i7&&Input Registers&\cr\noalign{\hrule} |
---|
191 | }}\hfil} |
---|
192 | @end tex |
---|
193 | @end ifset |
---|
194 | |
---|
195 | @ifset use-html |
---|
196 | @html |
---|
197 | <CENTER> |
---|
198 | <TABLE COLS=3 WIDTH="80%" BORDER=2> |
---|
199 | <TR><TD ALIGN=center><STRONG>Register Number</STRONG></TD> |
---|
200 | <TD ALIGN=center><STRONG>Register Names</STRONG></TD> |
---|
201 | <TD ALIGN=center><STRONG>Description</STRONG></TD> |
---|
202 | <TR><TD ALIGN=center>0 - 7</TD> |
---|
203 | <TD ALIGN=center>g0 - g7</TD> |
---|
204 | <TD ALIGN=center>Global Registers</TD></TR> |
---|
205 | <TR><TD ALIGN=center>8 - 15</TD> |
---|
206 | <TD ALIGN=center>o0 - o7</TD> |
---|
207 | <TD ALIGN=center>Output Registers</TD></TR> |
---|
208 | <TR><TD ALIGN=center>16 - 23</TD> |
---|
209 | <TD ALIGN=center>l0 - l7</TD> |
---|
210 | <TD ALIGN=center>Local Registers</TD></TR> |
---|
211 | <TR><TD ALIGN=center>24 - 31</TD> |
---|
212 | <TD ALIGN=center>i0 - i7</TD> |
---|
213 | <TD ALIGN=center>Input Registers</TD></TR> |
---|
214 | </TABLE> |
---|
215 | </CENTER> |
---|
216 | @end html |
---|
217 | @end ifset |
---|
218 | |
---|
219 | As mentioned above, some of the registers serve |
---|
220 | defined roles in the programming model. The following table |
---|
221 | describes the role of each of these registers: |
---|
222 | |
---|
223 | @ifset use-ascii |
---|
224 | @example |
---|
225 | @group |
---|
226 | +---------------+----------------+----------------------+ |
---|
227 | | Register Name | Alternate Name | Description | |
---|
228 | +---------------+----------------+----------------------+ |
---|
229 | | g0 | na | reads return 0 | |
---|
230 | | | | writes are ignored | |
---|
231 | +---------------+----------------+----------------------+ |
---|
232 | | o6 | sp | stack pointer | |
---|
233 | +---------------+----------------+----------------------+ |
---|
234 | | i6 | fp | frame pointer | |
---|
235 | +---------------+----------------+----------------------+ |
---|
236 | | i7 | na | return address | |
---|
237 | +---------------+----------------+----------------------+ |
---|
238 | @end group |
---|
239 | @end example |
---|
240 | @end ifset |
---|
241 | |
---|
242 | @ifset use-tex |
---|
243 | @sp 1 |
---|
244 | @tex |
---|
245 | \centerline{\vbox{\offinterlineskip\halign{ |
---|
246 | \vrule\strut#& |
---|
247 | \hbox to 1.75in{\enskip\hfil#\hfil}& |
---|
248 | \vrule#& |
---|
249 | \hbox to 1.75in{\enskip\hfil#\hfil}& |
---|
250 | \vrule#& |
---|
251 | \hbox to 1.75in{\enskip\hfil#\hfil}& |
---|
252 | \vrule#\cr |
---|
253 | \noalign{\hrule} |
---|
254 | &\bf Register Name &&\bf Alternate Names&&\bf Description&\cr\noalign{\hrule} |
---|
255 | &g0&&NA&&reads return 0; &\cr |
---|
256 | &&&&&writes are ignored&\cr\noalign{\hrule} |
---|
257 | &o6&&sp&&stack pointer&\cr\noalign{\hrule} |
---|
258 | &i6&&fp&&frame pointer&\cr\noalign{\hrule} |
---|
259 | &i7&&NA&&return address&\cr\noalign{\hrule} |
---|
260 | }}\hfil} |
---|
261 | @end tex |
---|
262 | @end ifset |
---|
263 | |
---|
264 | @ifset use-html |
---|
265 | @html |
---|
266 | <CENTER> |
---|
267 | <TABLE COLS=3 WIDTH="80%" BORDER=2> |
---|
268 | <TR><TD ALIGN=center><STRONG>Register Name</STRONG></TD> |
---|
269 | <TD ALIGN=center><STRONG>Alternate Name</STRONG></TD> |
---|
270 | <TD ALIGN=center><STRONG>Description</STRONG></TD></TR> |
---|
271 | <TR><TD ALIGN=center>g0</TD> |
---|
272 | <TD ALIGN=center>NA</TD> |
---|
273 | <TD ALIGN=center>reads return 0 ; writes are ignored</TD></TR> |
---|
274 | <TR><TD ALIGN=center>o6</TD> |
---|
275 | <TD ALIGN=center>sp</TD> |
---|
276 | <TD ALIGN=center>stack pointer</TD></TR> |
---|
277 | <TR><TD ALIGN=center>i6</TD> |
---|
278 | <TD ALIGN=center>fp</TD> |
---|
279 | <TD ALIGN=center>frame pointer</TD></TR> |
---|
280 | <TR><TD ALIGN=center>i7</TD> |
---|
281 | <TD ALIGN=center>NA</TD> |
---|
282 | <TD ALIGN=center>return address</TD></TR> |
---|
283 | </TABLE> |
---|
284 | </CENTER> |
---|
285 | @end html |
---|
286 | @end ifset |
---|
287 | |
---|
288 | |
---|
289 | @subsubsection Floating Point Registers |
---|
290 | |
---|
291 | The SPARC V9 architecture includes sixty-four, |
---|
292 | thirty-two bit registers. These registers may be viewed as |
---|
293 | follows: |
---|
294 | |
---|
295 | @itemize @bullet |
---|
296 | @item 32 32-bit single precision floating point or integer registers |
---|
297 | (f0, f1, ... f31) |
---|
298 | |
---|
299 | @item 32 64-bit double precision floating point registers (f0, f2, |
---|
300 | f4, ... f62) |
---|
301 | |
---|
302 | @item 16 128-bit extended precision floating point registers (f0, f4, |
---|
303 | f8, ... f60) |
---|
304 | @end itemize |
---|
305 | |
---|
306 | The floating point state register (fsr) specifies |
---|
307 | the behavior of the floating point unit for rounding, contains |
---|
308 | its condition codes, version specification, and trap information. |
---|
309 | |
---|
310 | @subsubsection Special Registers |
---|
311 | |
---|
312 | The SPARC architecture includes a number of special registers: |
---|
313 | @table @b |
---|
314 | |
---|
315 | @item @code{Ancillary State Registers (ASRs)} |
---|
316 | The ancillary state registers (ASRs) are optional state registers that |
---|
317 | may be privileged or nonprivileged. ASRs 16-31 are implementation- |
---|
318 | dependent. The SPARC V9 ASRs include: y, ccr, asi, tick, pc, fprs. |
---|
319 | The sun4u ASRs include: pcr, pic, dcr, gsr, softint set, softint clr, |
---|
320 | softint, and tick cmpr. The sun4v ASRs include: pcr, pic, gsr, soft- |
---|
321 | int set, softint clr, softint, tick cmpr, stick, and stick cmpr. |
---|
322 | |
---|
323 | @item @code{Processor State Register (pstate)} |
---|
324 | The privileged pstate register contains control fields for the proces- |
---|
325 | sorâs current state. Its flag fields include the interrupt enable, privi- |
---|
326 | leged mode, and enable FPU. |
---|
327 | |
---|
328 | @item @code{Processor Interrupt Level (pil)} |
---|
329 | The PIL specifies the interrupt level above which interrupts will be |
---|
330 | accepted. |
---|
331 | |
---|
332 | @item @code{Trap Registers} |
---|
333 | The trap handling mechanism of the SPARC V9 includes a number of |
---|
334 | registers, including: trap program counter (tpc), trap next pc (tnpc), |
---|
335 | trap state (tstate), trap type (tt), trap base address (tba), and trap |
---|
336 | level (tl). |
---|
337 | |
---|
338 | @item @code{Alternate Globals} |
---|
339 | The AG bit of the pstate register provides access to an alternate set |
---|
340 | of global registers. On sun4v, the AG bit is replaced by the global |
---|
341 | level (gl) register, providing access to at least two and at most eight |
---|
342 | alternate sets of globals. |
---|
343 | |
---|
344 | @item @code{Register Window registers} |
---|
345 | A number of registers assist in register window management. |
---|
346 | These include the current window pointer (cwp), savable windows |
---|
347 | (cansave), restorable windows (canrestore), clean windows (clean- |
---|
348 | win), other windows (otherwin), and window state (wstate). |
---|
349 | |
---|
350 | @end table |
---|
351 | |
---|
352 | @subsection Register Windows |
---|
353 | |
---|
354 | The SPARC architecture includes the concept of |
---|
355 | register windows. An overly simplistic way to think of these |
---|
356 | windows is to imagine them as being an infinite supply of |
---|
357 | "fresh" register sets available for each subroutine to use. In |
---|
358 | reality, they are much more complicated. |
---|
359 | |
---|
360 | The save instruction is used to obtain a new register window. |
---|
361 | This instruction increments the current window pointer, thus |
---|
362 | providing a new set of registers for use. This register set |
---|
363 | includes eight fresh local registers for use exclusively by |
---|
364 | this subroutine. When done with a register set, the restore |
---|
365 | instruction decrements the current window pointer and the |
---|
366 | previous register set is once again available. |
---|
367 | |
---|
368 | The two primary issues complicating the use of register windows |
---|
369 | are that (1) the set of register windows is finite, and (2) some |
---|
370 | registers are shared between adjacent registers windows. |
---|
371 | |
---|
372 | Because the set of register windows is finite, it is |
---|
373 | possible to execute enough save instructions without |
---|
374 | corresponding restore's to consume all of the register windows. |
---|
375 | This is easily accomplished in a high level language because |
---|
376 | each subroutine typically performs a save instruction upon |
---|
377 | entry. Thus having a subroutine call depth greater than the |
---|
378 | number of register windows will result in a window overflow |
---|
379 | condition. The window overflow condition generates a trap which |
---|
380 | must be handled in software. The window overflow trap handler |
---|
381 | is responsible for saving the contents of the oldest register |
---|
382 | window on the program stack. |
---|
383 | |
---|
384 | Similarly, the subroutines will eventually complete |
---|
385 | and begin to perform restore's. If the restore results in the |
---|
386 | need for a register window which has previously been written to |
---|
387 | memory as part of an overflow, then a window underflow condition |
---|
388 | results. Just like the window overflow, the window underflow |
---|
389 | condition must be handled in software by a trap handler. The |
---|
390 | window underflow trap handler is responsible for reloading the |
---|
391 | contents of the register window requested by the restore |
---|
392 | instruction from the program stack. |
---|
393 | |
---|
394 | The cansave, canrestore, otherwin, and cwp are used in conjunction |
---|
395 | to manage the finite set of register windows and detect the window |
---|
396 | overflow and underflow conditions. The first three of these |
---|
397 | registers must satisfy the invariant cansave + canrestore + otherwin = |
---|
398 | nwindow - 2, where nwindow is the number of register windows. |
---|
399 | The cwp contains the index of the register window currently in use. |
---|
400 | RTEMS does not use the cleanwin and otherwin registers. |
---|
401 | |
---|
402 | The save instruction increments the cwp modulo the number of |
---|
403 | register windows, and if cansave is 0 then it also generates a |
---|
404 | window overflow. Similarly, the restore instruction decrements the |
---|
405 | cwp modulo the number of register windows, and if canrestore is 0 then it |
---|
406 | also generates a window underflow. |
---|
407 | |
---|
408 | Unlike with the SPARC model, the SPARC-64 port does not assume that |
---|
409 | a register window is available for a trap. The window overflow |
---|
410 | and underflow conditions are not detected without hardware generating |
---|
411 | the trap. (These conditions can be detected by reading the register window |
---|
412 | registers and doing some simple arithmetic.) |
---|
413 | |
---|
414 | The window overflow and window underflow trap |
---|
415 | handlers are a critical part of the run-time environment for a |
---|
416 | SPARC application. The SPARC architectural specification allows |
---|
417 | for the number of register windows to be any power of two less |
---|
418 | than or equal to 32. The most common choice for SPARC |
---|
419 | implementations appears to be 8 register windows. This results |
---|
420 | in the cwp ranging in value from 0 to 7 on most implementations. |
---|
421 | |
---|
422 | The second complicating factor is the sharing of |
---|
423 | registers between adjacent register windows. While each |
---|
424 | register window has its own set of local registers, the input |
---|
425 | and output registers are shared between adjacent windows. The |
---|
426 | output registers for register window N are the same as the input |
---|
427 | registers for register window ((N + 1) modulo RW) where RW is |
---|
428 | the number of register windows. An alternative way to think of |
---|
429 | this is to remember how parameters are passed to a subroutine on |
---|
430 | the SPARC. The caller loads values into what are its output |
---|
431 | registers. Then after the callee executes a save instruction, |
---|
432 | those parameters are available in its input registers. This is |
---|
433 | a very efficient way to pass parameters as no data is actually |
---|
434 | moved by the save or restore instructions. |
---|
435 | |
---|
436 | @subsection Call and Return Mechanism |
---|
437 | |
---|
438 | The SPARC architecture supports a simple yet |
---|
439 | effective call and return mechanism. A subroutine is invoked |
---|
440 | via the call (call) instruction. This instruction places the |
---|
441 | return address in the caller's output register 7 (o7). After |
---|
442 | the callee executes a save instruction, this value is available |
---|
443 | in input register 7 (i7) until the corresponding restore |
---|
444 | instruction is executed. |
---|
445 | |
---|
446 | The callee returns to the caller via a jmp to the |
---|
447 | return address. There is a delay slot following this |
---|
448 | instruction which is commonly used to execute a restore |
---|
449 | instruction -- if a register window was allocated by this |
---|
450 | subroutine. |
---|
451 | |
---|
452 | It is important to note that the SPARC subroutine |
---|
453 | call and return mechanism does not automatically save and |
---|
454 | restore any registers. This is accomplished via the save and |
---|
455 | restore instructions which manage the set of registers windows. |
---|
456 | This allows for the compiler to generate leaf-optimized functions |
---|
457 | that utilize the callerâs output registers without using save and restore. |
---|
458 | |
---|
459 | @subsection Calling Mechanism |
---|
460 | |
---|
461 | All RTEMS directives are invoked using the regular |
---|
462 | SPARC calling convention via the call instruction. |
---|
463 | |
---|
464 | @subsection Register Usage |
---|
465 | |
---|
466 | As discussed above, the call instruction does not |
---|
467 | automatically save any registers. The save and restore |
---|
468 | instructions are used to allocate and deallocate register |
---|
469 | windows. When a register window is allocated, the new set of |
---|
470 | local registers are available for the exclusive use of the |
---|
471 | subroutine which allocated this register set. |
---|
472 | |
---|
473 | @subsection Parameter Passing |
---|
474 | |
---|
475 | RTEMS assumes that arguments are placed in the |
---|
476 | caller's output registers with the first argument in output |
---|
477 | register 0 (o0), the second argument in output register 1 (o1), |
---|
478 | and so forth. Until the callee executes a save instruction, the |
---|
479 | parameters are still visible in the output registers. After the |
---|
480 | callee executes a save instruction, the parameters are visible |
---|
481 | in the corresponding input registers. The following pseudo-code |
---|
482 | illustrates the typical sequence used to call a RTEMS directive |
---|
483 | with three (3) arguments: |
---|
484 | |
---|
485 | @example |
---|
486 | load third argument into o2 |
---|
487 | load second argument into o1 |
---|
488 | load first argument into o0 |
---|
489 | invoke directive |
---|
490 | @end example |
---|
491 | |
---|
492 | @subsection User-Provided Routines |
---|
493 | |
---|
494 | All user-provided routines invoked by RTEMS, such as |
---|
495 | user extensions, device drivers, and MPCI routines, must also |
---|
496 | adhere to these calling conventions. |
---|
497 | |
---|
498 | @c |
---|
499 | @c COPYRIGHT (c) 1988-2002. |
---|
500 | @c On-Line Applications Research Corporation (OAR). |
---|
501 | @c All rights reserved. |
---|
502 | |
---|
503 | @section Memory Model |
---|
504 | |
---|
505 | |
---|
506 | A processor may support any combination of memory |
---|
507 | models ranging from pure physical addressing to complex demand |
---|
508 | paged virtual memory systems. RTEMS supports a flat memory |
---|
509 | model which ranges contiguously over the processor's allowable |
---|
510 | address space. RTEMS does not support segmentation or virtual |
---|
511 | memory of any kind. The appropriate memory model for RTEMS |
---|
512 | provided by the targeted processor and related characteristics |
---|
513 | of that model are described in this chapter. |
---|
514 | |
---|
515 | @subsection Flat Memory Model |
---|
516 | |
---|
517 | The SPARC-64 architecture supports a flat 64-bit address space with |
---|
518 | addresses ranging from 0x0000000000000000 to 0xFFFFFFFFFFFFFFFF. |
---|
519 | Each address is represented by a 64-bit value (and an 8-bit address |
---|
520 | space identifider or ASI) and is byte addressable. The address |
---|
521 | may be used to reference a single byte, half-word (2-bytes), |
---|
522 | word (4 bytes), doubleword (8 bytes), or quad-word (16 bytes). |
---|
523 | Memory accesses within this address space are performed |
---|
524 | in big endian fashion by the SPARC. Memory accesses which are not |
---|
525 | properly aligned generate a "memory address not aligned" trap |
---|
526 | (type number 0x34). The following table lists the alignment |
---|
527 | requirements for a variety of data accesses: |
---|
528 | |
---|
529 | @ifset use-ascii |
---|
530 | @example |
---|
531 | @group |
---|
532 | +--------------+-----------------------+ |
---|
533 | | Data Type | Alignment Requirement | |
---|
534 | +--------------+-----------------------+ |
---|
535 | | byte | 1 | |
---|
536 | | half-word | 2 | |
---|
537 | | word | 4 | |
---|
538 | | doubleword | 8 | |
---|
539 | | quadword | 16 | |
---|
540 | +--------------+-----------------------+ |
---|
541 | @end group |
---|
542 | @end example |
---|
543 | @end ifset |
---|
544 | |
---|
545 | @ifset use-tex |
---|
546 | @sp 1 |
---|
547 | @tex |
---|
548 | \centerline{\vbox{\offinterlineskip\halign{ |
---|
549 | \vrule\strut#& |
---|
550 | \hbox to 1.75in{\enskip\hfil#\hfil}& |
---|
551 | \vrule#& |
---|
552 | \hbox to 1.75in{\enskip\hfil#\hfil}& |
---|
553 | \vrule#\cr |
---|
554 | \noalign{\hrule} |
---|
555 | &\bf Data Type &&\bf Alignment Requirement&\cr\noalign{\hrule} |
---|
556 | &byte&&1&\cr\noalign{\hrule} |
---|
557 | &half-word&&2&\cr\noalign{\hrule} |
---|
558 | &word&&4&\cr\noalign{\hrule} |
---|
559 | &doubleword&&8&\cr\noalign{\hrule} |
---|
560 | &quadword&&16&\cr\noalign{\hrule} |
---|
561 | }}\hfil} |
---|
562 | @end tex |
---|
563 | @end ifset |
---|
564 | |
---|
565 | @ifset use-html |
---|
566 | @html |
---|
567 | <CENTER> |
---|
568 | <TABLE COLS=2 WIDTH="60%" BORDER=2> |
---|
569 | <TR><TD ALIGN=center><STRONG>Data Type</STRONG></TD> |
---|
570 | <TD ALIGN=center><STRONG>Alignment Requirement</STRONG></TD></TR> |
---|
571 | <TR><TD ALIGN=center>byte</TD> |
---|
572 | <TD ALIGN=center>1</TD></TR> |
---|
573 | <TR><TD ALIGN=center>half-word</TD> |
---|
574 | <TD ALIGN=center>2</TD></TR> |
---|
575 | <TR><TD ALIGN=center>word</TD> |
---|
576 | <TD ALIGN=center>4</TD></TR> |
---|
577 | <TR><TD ALIGN=center>doubleword</TD> |
---|
578 | <TD ALIGN=center>8</TD></TR> |
---|
579 | <TR><TD ALIGN=center>quadword</TD> |
---|
580 | <TD ALIGN=center>16</TD></TR> |
---|
581 | </TABLE> |
---|
582 | </CENTER> |
---|
583 | @end html |
---|
584 | @end ifset |
---|
585 | |
---|
586 | RTEMS currently does not support any SPARC Memory Management |
---|
587 | Units, therefore, virtual memory or segmentation systems |
---|
588 | involving the SPARC are not supported. |
---|
589 | |
---|
590 | @c |
---|
591 | @c COPYRIGHT (c) 1988-2002. |
---|
592 | @c On-Line Applications Research Corporation (OAR). |
---|
593 | @c All rights reserved. |
---|
594 | |
---|
595 | @section Interrupt Processing |
---|
596 | |
---|
597 | RTEMS and associated documentation uses the terms |
---|
598 | interrupt and vector. In the SPARC architecture, these terms |
---|
599 | correspond to traps and trap type, respectively. The terms will |
---|
600 | be used interchangeably in this manual. Note that in the SPARC manuals, |
---|
601 | interrupts are a subset of the traps that are delivered to software |
---|
602 | interrupt handlers. |
---|
603 | |
---|
604 | @subsection Synchronous Versus Asynchronous Traps |
---|
605 | |
---|
606 | The SPARC architecture includes two classes of traps: |
---|
607 | synchronous (precise) and asynchronous (deferred). |
---|
608 | Asynchronous traps occur when an |
---|
609 | external event interrupts the processor. These traps are not |
---|
610 | associated with any instruction executed by the processor and |
---|
611 | logically occur between instructions. The instruction currently |
---|
612 | in the execute stage of the processor is allowed to complete |
---|
613 | although subsequent instructions are annulled. The return |
---|
614 | address reported by the processor for asynchronous traps is the |
---|
615 | pair of instructions following the current instruction. |
---|
616 | |
---|
617 | Synchronous traps are caused by the actions of an |
---|
618 | instruction. The trap stimulus in this case either occurs |
---|
619 | internally to the processor or is from an external signal that |
---|
620 | was provoked by the instruction. These traps are taken |
---|
621 | immediately and the instruction that caused the trap is aborted |
---|
622 | before any state changes occur in the processor itself. The |
---|
623 | return address reported by the processor for synchronous traps |
---|
624 | is the instruction which caused the trap and the following |
---|
625 | instruction. |
---|
626 | |
---|
627 | @subsection Vectoring of Interrupt Handler |
---|
628 | |
---|
629 | Upon receipt of an interrupt the SPARC automatically |
---|
630 | performs the following actions: |
---|
631 | |
---|
632 | @itemize @bullet |
---|
633 | @item The trap level is set. This provides access to a fresh set of |
---|
634 | privileged trap-state registers used to save the current state, |
---|
635 | in effect, pushing a frame on the trap stack. |
---|
636 | TL <- TL + 1 |
---|
637 | @item Existing state is preserved |
---|
638 | @itemize @bullet |
---|
639 | @item TSTATE[TL].CCR <- CCR |
---|
640 | @item TSTATE[TL].ASI <- ASI |
---|
641 | @item TSTATE[TL].PSTATE <- PSTATE |
---|
642 | @item TSTATE[TL].CWP <- CWP |
---|
643 | @item TPC[TL] <- PC |
---|
644 | @item TNPC[TL] <- nPC |
---|
645 | @end itemize |
---|
646 | @item The trap type is preserved. TT[TL] <- the trap type |
---|
647 | @item The PSTATE register is updated to a predefined state |
---|
648 | @itemize @bullet |
---|
649 | @item PSTATE.MM is unchanged |
---|
650 | @item PSTATE.RED <- 0 |
---|
651 | @item PSTATE.PEF <- 1 if FPU is present, 0 otherwise |
---|
652 | @item PSTATE.AM <- 0 (address masking is turned off) |
---|
653 | @item PSTATE.PRIV <- 1 (the processor enters privileged mode) |
---|
654 | @item PSTATE.IE <- 0 (interrupts are disabled) |
---|
655 | @item PSTATE.AG <- 1 (global regs are replaced with alternate globals) |
---|
656 | @item PSTATE.CLE <- PSTATE.TLE (set endian mode for traps) |
---|
657 | @end itemize |
---|
658 | @item For a register-window trap only, CWP is set to point to the register |
---|
659 | window that must be accessed by the trap-handler software, that is: |
---|
660 | @itemize @bullet |
---|
661 | @item If TT[TL] = 0x24 (a clean window trap), then CWP <- CWP + 1. |
---|
662 | @item If (0x80 <= TT[TL] <= 0xBF) (window spill trap), then CWP <- CWP + |
---|
663 | CANSAVE + 2. |
---|
664 | @item If (0xC0 <= TT[TL] <= 0xFF) (window fill trap), then CWP <- CWP1. |
---|
665 | @item For non-register-window traps, CWP is not changed. |
---|
666 | @end itemize |
---|
667 | @item Control is transferred into the trap table: |
---|
668 | @itemize @bullet |
---|
669 | @item PC <- TBA<63:15> (TL>0) TT[TL] 0 0000 |
---|
670 | @item nPC <- TBA<63:15> (TL>0) TT[TL] 0 0100 |
---|
671 | @item where (TL>0) is 0 if TL = 0, and 1 if TL > 0. |
---|
672 | @end itemize |
---|
673 | |
---|
674 | @end itemize |
---|
675 | |
---|
676 | In order to safely invoke a subroutine during trap handling, traps must be |
---|
677 | enabled to allow for the possibility of register window overflow and |
---|
678 | underflow traps. |
---|
679 | |
---|
680 | If the interrupt handler was installed as an RTEMS |
---|
681 | interrupt handler, then upon receipt of the interrupt, the |
---|
682 | processor passes control to the RTEMS interrupt handler which |
---|
683 | performs the following actions: |
---|
684 | |
---|
685 | @itemize @bullet |
---|
686 | @item saves the state of the interrupted task on it's stack, |
---|
687 | |
---|
688 | @item switches the processor to trap level 0, |
---|
689 | |
---|
690 | @item if this is the outermost (i.e. non-nested) interrupt, |
---|
691 | then the RTEMS interrupt handler switches from the current stack |
---|
692 | to the interrupt stack, |
---|
693 | |
---|
694 | @item enables traps, |
---|
695 | |
---|
696 | @item invokes the vectors to a user interrupt service routine (ISR). |
---|
697 | @end itemize |
---|
698 | |
---|
699 | Asynchronous interrupts are ignored while traps are |
---|
700 | disabled. Synchronous traps which occur while traps are |
---|
701 | disabled may result in the CPU being forced into an error mode. |
---|
702 | |
---|
703 | A nested interrupt is processed similarly with the |
---|
704 | exception that the current stack need not be switched to the |
---|
705 | interrupt stack. |
---|
706 | |
---|
707 | @subsection Traps and Register Windows |
---|
708 | |
---|
709 | XXX |
---|
710 | |
---|
711 | @subsection Interrupt Levels |
---|
712 | |
---|
713 | Sixteen levels (0-15) of interrupt priorities are |
---|
714 | supported by the SPARC architecture with level fifteen (15) |
---|
715 | being the highest priority. Level zero (0) indicates that |
---|
716 | interrupts are fully enabled. Interrupt requests for interrupts |
---|
717 | with priorities less than or equal to the current interrupt mask |
---|
718 | level are ignored. |
---|
719 | |
---|
720 | Although RTEMS supports 256 interrupt levels, the |
---|
721 | SPARC only supports sixteen. RTEMS interrupt levels 0 through |
---|
722 | 15 directly correspond to SPARC processor interrupt levels. All |
---|
723 | other RTEMS interrupt levels are undefined and their behavior is |
---|
724 | unpredictable. |
---|
725 | |
---|
726 | @subsection Disabling of Interrupts by RTEMS |
---|
727 | |
---|
728 | XXX |
---|
729 | |
---|
730 | @subsection Interrupt Stack |
---|
731 | |
---|
732 | The SPARC architecture does not provide for a |
---|
733 | dedicated interrupt stack. Thus by default, trap handlers would |
---|
734 | execute on the stack of the RTEMS task which they interrupted. |
---|
735 | This artificially inflates the stack requirements for each task |
---|
736 | since EVERY task stack would have to include enough space to |
---|
737 | account for the worst case interrupt stack requirements in |
---|
738 | addition to it's own worst case usage. RTEMS addresses this |
---|
739 | problem on the SPARC by providing a dedicated interrupt stack |
---|
740 | managed by software. |
---|
741 | |
---|
742 | During system initialization, RTEMS allocates the |
---|
743 | interrupt stack from the Workspace Area. The amount of memory |
---|
744 | allocated for the interrupt stack is determined by the |
---|
745 | interrupt_stack_size field in the CPU Configuration Table. As |
---|
746 | part of processing a non-nested interrupt, RTEMS will switch to |
---|
747 | the interrupt stack before invoking the installed handler. |
---|
748 | |
---|
749 | @c |
---|
750 | @c COPYRIGHT (c) 1988-2002. |
---|
751 | @c On-Line Applications Research Corporation (OAR). |
---|
752 | @c All rights reserved. |
---|
753 | |
---|
754 | @section Default Fatal Error Processing |
---|
755 | |
---|
756 | |
---|
757 | Upon detection of a fatal error by either the |
---|
758 | application or RTEMS the fatal error manager is invoked. The |
---|
759 | fatal error manager will invoke the user-supplied fatal error |
---|
760 | handlers. If no user-supplied handlers are configured, the |
---|
761 | RTEMS provided default fatal error handler is invoked. If the |
---|
762 | user-supplied fatal error handlers return to the executive the |
---|
763 | default fatal error handler is then invoked. This chapter |
---|
764 | describes the precise operations of the default fatal error |
---|
765 | handler. |
---|
766 | |
---|
767 | @subsection Default Fatal Error Handler Operations |
---|
768 | |
---|
769 | The default fatal error handler which is invoked by |
---|
770 | the fatal_error_occurred directive when there is no user handler |
---|
771 | configured or the user handler returns control to RTEMS. The |
---|
772 | default fatal error handler disables processor interrupts to |
---|
773 | level 15, places the error code in g1, and goes into an infinite |
---|
774 | loop to simulate a halt processor instruction. |
---|
775 | |
---|
776 | |
---|
777 | @c |
---|
778 | @c COPYRIGHT (c) 1988-2002. |
---|
779 | @c On-Line Applications Research Corporation (OAR). |
---|
780 | @c All rights reserved. |
---|
781 | |
---|
782 | @section Board Support Packages |
---|
783 | |
---|
784 | An RTEMS Board Support Package (BSP) must be designed |
---|
785 | to support a particular processor and target board combination. |
---|
786 | This chapter presents a discussion of SPARC specific BSP issues. |
---|
787 | For more information on developing a BSP, refer to the chapter |
---|
788 | titled Board Support Packages in the RTEMS |
---|
789 | Applications User's Guide. |
---|
790 | |
---|
791 | @subsection HelenOS and Open Firmware |
---|
792 | The provided BSPs make use of some bootstrap and low-level hardware code |
---|
793 | of the HelenOS operating system. These files can be found in the shared/helenos |
---|
794 | directory of the sparc64 bsp directory. Consult the sources for more |
---|
795 | detailed information. |
---|
796 | |
---|
797 | The shared BSP code also uses the Open Firmware interface to re-use firmware |
---|
798 | code, primarily for console support and default trap handlers. |
---|
799 | |
---|