1 | @c |
---|
2 | @c COPYRIGHT (c) 1988-1996. |
---|
3 | @c On-Line Applications Research Corporation (OAR). |
---|
4 | @c All rights reserved. |
---|
5 | @c |
---|
6 | @c $Id$ |
---|
7 | @c |
---|
8 | |
---|
9 | @ifinfo |
---|
10 | @node Calling Conventions, Calling Conventions Introduction, CPU Model Dependent Features CPU Model Implementation Notes, Top |
---|
11 | @end ifinfo |
---|
12 | @chapter Calling Conventions |
---|
13 | @ifinfo |
---|
14 | @menu |
---|
15 | * Calling Conventions Introduction:: |
---|
16 | * Calling Conventions Programming Model:: |
---|
17 | * Calling Conventions Register Windows:: |
---|
18 | * Calling Conventions Call and Return Mechanism:: |
---|
19 | * Calling Conventions Calling Mechanism:: |
---|
20 | * Calling Conventions Register Usage:: |
---|
21 | * Calling Conventions Parameter Passing:: |
---|
22 | * Calling Conventions User-Provided Routines:: |
---|
23 | @end menu |
---|
24 | @end ifinfo |
---|
25 | |
---|
26 | @ifinfo |
---|
27 | @node Calling Conventions Introduction, Calling Conventions Programming Model, Calling Conventions, Calling Conventions |
---|
28 | @end ifinfo |
---|
29 | @section Introduction |
---|
30 | |
---|
31 | Each high-level language compiler generates |
---|
32 | subroutine entry and exit code based upon a set of rules known |
---|
33 | as the compiler's calling convention. These rules address the |
---|
34 | following issues: |
---|
35 | |
---|
36 | @itemize @bullet |
---|
37 | @item register preservation and usage |
---|
38 | |
---|
39 | @item parameter passing |
---|
40 | |
---|
41 | @item call and return mechanism |
---|
42 | @end itemize |
---|
43 | |
---|
44 | A compiler's calling convention is of importance when |
---|
45 | interfacing to subroutines written in another language either |
---|
46 | assembly or high-level. Even when the high-level language and |
---|
47 | target processor are the same, different compilers may use |
---|
48 | different calling conventions. As a result, calling conventions |
---|
49 | are both processor and compiler dependent. |
---|
50 | |
---|
51 | @ifinfo |
---|
52 | @node Calling Conventions Programming Model, Non-Floating Point Registers, Calling Conventions Introduction, Calling Conventions |
---|
53 | @end ifinfo |
---|
54 | @section Programming Model |
---|
55 | @ifinfo |
---|
56 | @menu |
---|
57 | * Non-Floating Point Registers:: |
---|
58 | * Floating Point Registers:: |
---|
59 | * Special Registers:: |
---|
60 | @end menu |
---|
61 | @end ifinfo |
---|
62 | |
---|
63 | This section discusses the programming model for the |
---|
64 | SPARC architecture. |
---|
65 | |
---|
66 | @ifinfo |
---|
67 | @node Non-Floating Point Registers, Floating Point Registers, Calling Conventions Programming Model, Calling Conventions Programming Model |
---|
68 | @end ifinfo |
---|
69 | @subsection Non-Floating Point Registers |
---|
70 | |
---|
71 | The SPARC architecture defines thirty-two |
---|
72 | non-floating point registers directly visible to the programmer. |
---|
73 | These are divided into four sets: |
---|
74 | |
---|
75 | @itemize @bullet |
---|
76 | @item input registers |
---|
77 | |
---|
78 | @item local registers |
---|
79 | |
---|
80 | @item output registers |
---|
81 | |
---|
82 | @item global registers |
---|
83 | @end itemize |
---|
84 | |
---|
85 | Each register is referred to by either two or three |
---|
86 | names in the SPARC reference manuals. First, the registers are |
---|
87 | referred to as r0 through r31 or with the alternate notation |
---|
88 | r[0] through r[31]. Second, each register is a member of one of |
---|
89 | the four sets listed above. Finally, some registers have an |
---|
90 | architecturally defined role in the programming model which |
---|
91 | provides an alternate name. The following table describes the |
---|
92 | mapping between the 32 registers and the register sets: |
---|
93 | |
---|
94 | @ifset use-ascii |
---|
95 | @example |
---|
96 | @group |
---|
97 | +-----------------+----------------+------------------+ |
---|
98 | | Register Number | Register Names | Description | |
---|
99 | +-----------------+----------------+------------------+ |
---|
100 | | 0 - 7 | g0 - g7 | Global Registers | |
---|
101 | +-----------------+----------------+------------------+ |
---|
102 | | 8 - 15 | o0 - o7 | Output Registers | |
---|
103 | +-----------------+----------------+------------------+ |
---|
104 | | 16 - 23 | l0 - l7 | Local Registers | |
---|
105 | +-----------------+----------------+------------------+ |
---|
106 | | 24 - 31 | i0 - i7 | Input Registers | |
---|
107 | +-----------------+----------------+------------------+ |
---|
108 | @end group |
---|
109 | @end example |
---|
110 | @end ifset |
---|
111 | |
---|
112 | @ifset use-tex |
---|
113 | @sp 1 |
---|
114 | @tex |
---|
115 | \centerline{\vbox{\offinterlineskip\halign{ |
---|
116 | \vrule\strut#& |
---|
117 | \hbox to 1.75in{\enskip\hfil#\hfil}& |
---|
118 | \vrule#& |
---|
119 | \hbox to 1.75in{\enskip\hfil#\hfil}& |
---|
120 | \vrule#& |
---|
121 | \hbox to 1.75in{\enskip\hfil#\hfil}& |
---|
122 | \vrule#\cr |
---|
123 | \noalign{\hrule} |
---|
124 | &\bf Register Number &&\bf Register Names&&\bf Description&\cr\noalign{\hrule} |
---|
125 | &0 - 7&&g0 - g7&&Global Registers&\cr\noalign{\hrule} |
---|
126 | &8 - 15&&o0 - o7&&Output Registers&\cr\noalign{\hrule} |
---|
127 | &16 - 23&&l0 - l7&&Local Registers&\cr\noalign{\hrule} |
---|
128 | &24 - 31&&i0 - i7&&Input Registers&\cr\noalign{\hrule} |
---|
129 | }}\hfil} |
---|
130 | @end tex |
---|
131 | @end ifset |
---|
132 | |
---|
133 | @ifset use-html |
---|
134 | @html |
---|
135 | <CENTER> |
---|
136 | <TABLE COLS=3 WIDTH="80%" BORDER=2> |
---|
137 | <TR><TD ALIGN=center><STRONG>Register Number</STRONG></TD> |
---|
138 | <TD ALIGN=center><STRONG>Register Names</STRONG></TD> |
---|
139 | <TD ALIGN=center><STRONG>Description</STRONG></TD> |
---|
140 | <TR><TD ALIGN=center>0 - 7</TD> |
---|
141 | <TD ALIGN=center>g0 - g7</TD> |
---|
142 | <TD ALIGN=center>Global Registers</TD></TR> |
---|
143 | <TR><TD ALIGN=center>8 - 15</TD> |
---|
144 | <TD ALIGN=center>o0 - o7</TD> |
---|
145 | <TD ALIGN=center>Output Registers</TD></TR> |
---|
146 | <TR><TD ALIGN=center>16 - 23</TD> |
---|
147 | <TD ALIGN=center>l0 - l7</TD> |
---|
148 | <TD ALIGN=center>Local Registers</TD></TR> |
---|
149 | <TR><TD ALIGN=center>24 - 31</TD> |
---|
150 | <TD ALIGN=center>i0 - i7</TD> |
---|
151 | <TD ALIGN=center>Input Registers</TD></TR> |
---|
152 | </TABLE> |
---|
153 | </CENTER> |
---|
154 | @end html |
---|
155 | @end ifset |
---|
156 | |
---|
157 | As mentioned above, some of the registers serve |
---|
158 | defined roles in the programming model. The following table |
---|
159 | describes the role of each of these registers: |
---|
160 | |
---|
161 | @ifset use-ascii |
---|
162 | @example |
---|
163 | @group |
---|
164 | +---------------+----------------+----------------------+ |
---|
165 | | Register Name | Alternate Name | Description | |
---|
166 | +---------------+----------------+----------------------+ |
---|
167 | | g0 | na | reads return 0 | |
---|
168 | | | | writes are ignored | |
---|
169 | +---------------+----------------+----------------------+ |
---|
170 | | o6 | sp | stack pointer | |
---|
171 | +---------------+----------------+----------------------+ |
---|
172 | | i6 | fp | frame pointer | |
---|
173 | +---------------+----------------+----------------------+ |
---|
174 | | i7 | na | return address | |
---|
175 | +---------------+----------------+----------------------+ |
---|
176 | @end group |
---|
177 | @end example |
---|
178 | @end ifset |
---|
179 | |
---|
180 | @ifset use-tex |
---|
181 | @sp 1 |
---|
182 | @tex |
---|
183 | \centerline{\vbox{\offinterlineskip\halign{ |
---|
184 | \vrule\strut#& |
---|
185 | \hbox to 1.75in{\enskip\hfil#\hfil}& |
---|
186 | \vrule#& |
---|
187 | \hbox to 1.75in{\enskip\hfil#\hfil}& |
---|
188 | \vrule#& |
---|
189 | \hbox to 1.75in{\enskip\hfil#\hfil}& |
---|
190 | \vrule#\cr |
---|
191 | \noalign{\hrule} |
---|
192 | &\bf Register Name &&\bf Alternate Names&&\bf Description&\cr\noalign{\hrule} |
---|
193 | &g0&&NA&&reads return 0; &\cr |
---|
194 | &&&&&writes are ignored&\cr\noalign{\hrule} |
---|
195 | &o6&&sp&&stack pointer&\cr\noalign{\hrule} |
---|
196 | &i6&&fp&&frame pointer&\cr\noalign{\hrule} |
---|
197 | &i7&&NA&&return address&\cr\noalign{\hrule} |
---|
198 | }}\hfil} |
---|
199 | @end tex |
---|
200 | @end ifset |
---|
201 | |
---|
202 | @ifset use-html |
---|
203 | @html |
---|
204 | <CENTER> |
---|
205 | <TABLE COLS=3 WIDTH="80%" BORDER=2> |
---|
206 | <TR><TD ALIGN=center><STRONG>Register Name</STRONG></TD> |
---|
207 | <TD ALIGN=center><STRONG>Alternate Name</STRONG></TD> |
---|
208 | <TD ALIGN=center><STRONG>Description</STRONG></TD></TR> |
---|
209 | <TR><TD ALIGN=center>g0</TD> |
---|
210 | <TD ALIGN=center>NA</TD> |
---|
211 | <TD ALIGN=center>reads return 0 ; writes are ignored</TD></TR> |
---|
212 | <TR><TD ALIGN=center>o6</TD> |
---|
213 | <TD ALIGN=center>sp</TD> |
---|
214 | <TD ALIGN=center>stack pointer</TD></TR> |
---|
215 | <TR><TD ALIGN=center>i6</TD> |
---|
216 | <TD ALIGN=center>fp</TD> |
---|
217 | <TD ALIGN=center>frame pointer</TD></TR> |
---|
218 | <TR><TD ALIGN=center>i7</TD> |
---|
219 | <TD ALIGN=center>NA</TD> |
---|
220 | <TD ALIGN=center>return address</TD></TR> |
---|
221 | </TABLE> |
---|
222 | </CENTER> |
---|
223 | @end html |
---|
224 | @end ifset |
---|
225 | |
---|
226 | |
---|
227 | @ifinfo |
---|
228 | @node Floating Point Registers, Special Registers, Non-Floating Point Registers, Calling Conventions Programming Model |
---|
229 | @end ifinfo |
---|
230 | @subsection Floating Point Registers |
---|
231 | |
---|
232 | The SPARC V7 architecture includes thirty-two, |
---|
233 | thirty-two bit registers. These registers may be viewed as |
---|
234 | follows: |
---|
235 | |
---|
236 | @itemize @bullet |
---|
237 | @item 32 single precision floating point or integer registers |
---|
238 | (f0, f1, ... f31) |
---|
239 | |
---|
240 | @item 16 double precision floating point registers (f0, f2, |
---|
241 | f4, ... f30) |
---|
242 | |
---|
243 | @item 8 extended precision floating point registers (f0, f4, |
---|
244 | f8, ... f28) |
---|
245 | @end itemize |
---|
246 | |
---|
247 | The floating point status register (fpsr) specifies |
---|
248 | the behavior of the floating point unit for rounding, contains |
---|
249 | its condition codes, version specification, and trap information. |
---|
250 | |
---|
251 | A queue of the floating point instructions which have |
---|
252 | started execution but not yet completed is maintained. This |
---|
253 | queue is needed to support the multiple cycle nature of floating |
---|
254 | point operations and to aid floating point exception trap |
---|
255 | handlers. Once a floating point exception has been encountered, |
---|
256 | the queue is frozen until it is emptied by the trap handler. |
---|
257 | The floating point queue is loaded by launching instructions. |
---|
258 | It is emptied normally when the floating point completes all |
---|
259 | outstanding instructions and by floating point exception |
---|
260 | handlers with the store double floating point queue (stdfq) |
---|
261 | instruction. |
---|
262 | |
---|
263 | @ifinfo |
---|
264 | @node Special Registers, Calling Conventions Register Windows, Floating Point Registers, Calling Conventions Programming Model |
---|
265 | @end ifinfo |
---|
266 | @subsection Special Registers |
---|
267 | |
---|
268 | The SPARC architecture includes two special registers |
---|
269 | which are critical to the programming model: the Processor State |
---|
270 | Register (psr) and the Window Invalid Mask (wim). The psr |
---|
271 | contains the condition codes, processor interrupt level, trap |
---|
272 | enable bit, supervisor mode and previous supervisor mode bits, |
---|
273 | version information, floating point unit and coprocessor enable |
---|
274 | bits, and the current window pointer (cwp). The cwp field of |
---|
275 | the psr and wim register are used to manage the register windows |
---|
276 | in the SPARC architecture. The register windows are discussed |
---|
277 | in more detail below. |
---|
278 | |
---|
279 | @ifinfo |
---|
280 | @node Calling Conventions Register Windows, Calling Conventions Call and Return Mechanism, Special Registers, Calling Conventions |
---|
281 | @end ifinfo |
---|
282 | @section Register Windows |
---|
283 | |
---|
284 | The SPARC architecture includes the concept of |
---|
285 | register windows. An overly simplistic way to think of these |
---|
286 | windows is to imagine them as being an infinite supply of |
---|
287 | "fresh" register sets available for each subroutine to use. In |
---|
288 | reality, they are much more complicated. |
---|
289 | |
---|
290 | The save instruction is used to obtain a new register |
---|
291 | window. This instruction decrements the current window pointer, |
---|
292 | thus providing a new set of registers for use. This register |
---|
293 | set includes eight fresh local registers for use exclusively by |
---|
294 | this subroutine. When done with a register set, the restore |
---|
295 | instruction increments the current window pointer and the |
---|
296 | previous register set is once again available. |
---|
297 | |
---|
298 | The two primary issues complicating the use of |
---|
299 | register windows are that (1) the set of register windows is |
---|
300 | finite, and (2) some registers are shared between adjacent |
---|
301 | registers windows. |
---|
302 | |
---|
303 | Because the set of register windows is finite, it is |
---|
304 | possible to execute enough save instructions without |
---|
305 | corresponding restore's to consume all of the register windows. |
---|
306 | This is easily accomplished in a high level language because |
---|
307 | each subroutine typically performs a save instruction upon |
---|
308 | entry. Thus having a subroutine call depth greater than the |
---|
309 | number of register windows will result in a window overflow |
---|
310 | condition. The window overflow condition generates a trap which |
---|
311 | must be handled in software. The window overflow trap handler |
---|
312 | is responsible for saving the contents of the oldest register |
---|
313 | window on the program stack. |
---|
314 | |
---|
315 | Similarly, the subroutines will eventually complete |
---|
316 | and begin to perform restore's. If the restore results in the |
---|
317 | need for a register window which has previously been written to |
---|
318 | memory as part of an overflow, then a window underflow condition |
---|
319 | results. Just like the window overflow, the window underflow |
---|
320 | condition must be handled in software by a trap handler. The |
---|
321 | window underflow trap handler is responsible for reloading the |
---|
322 | contents of the register window requested by the restore |
---|
323 | instruction from the program stack. |
---|
324 | |
---|
325 | The Window Invalid Mask (wim) and the Current Window |
---|
326 | Pointer (cwp) field in the psr are used in conjunction to manage |
---|
327 | the finite set of register windows and detect the window |
---|
328 | overflow and underflow conditions. The cwp contains the index |
---|
329 | of the register window currently in use. The save instruction |
---|
330 | decrements the cwp modulo the number of register windows. |
---|
331 | Similarly, the restore instruction increments the cwp modulo the |
---|
332 | number of register windows. Each bit in the wim represents |
---|
333 | represents whether a register window contains valid information. |
---|
334 | The value of 0 indicates the register window is valid and 1 |
---|
335 | indicates it is invalid. When a save instruction causes the cwp |
---|
336 | to point to a register window which is marked as invalid, a |
---|
337 | window overflow condition results. Conversely, the restore |
---|
338 | instruction may result in a window underflow condition. |
---|
339 | |
---|
340 | Other than the assumption that a register window is |
---|
341 | always available for trap (i.e. interrupt) handlers, the SPARC |
---|
342 | architecture places no limits on the number of register windows |
---|
343 | simultaneously marked as invalid (i.e. number of bits set in the |
---|
344 | wim). However, RTEMS assumes that only one register window is |
---|
345 | marked invalid at a time (i.e. only one bit set in the wim). |
---|
346 | This makes the maximum possible number of register windows |
---|
347 | available to the user while still meeting the requirement that |
---|
348 | window overflow and underflow conditions can be detected. |
---|
349 | |
---|
350 | The window overflow and window underflow trap |
---|
351 | handlers are a critical part of the run-time environment for a |
---|
352 | SPARC application. The SPARC architectural specification allows |
---|
353 | for the number of register windows to be any power of two less |
---|
354 | than or equal to 32. The most common choice for SPARC |
---|
355 | implementations appears to be 8 register windows. This results |
---|
356 | in the cwp ranging in value from 0 to 7 on most implementations. |
---|
357 | |
---|
358 | |
---|
359 | The second complicating factor is the sharing of |
---|
360 | registers between adjacent register windows. While each |
---|
361 | register window has its own set of local registers, the input |
---|
362 | and output registers are shared between adjacent windows. The |
---|
363 | output registers for register window N are the same as the input |
---|
364 | registers for register window ((N - 1) modulo RW) where RW is |
---|
365 | the number of register windows. An alternative way to think of |
---|
366 | this is to remember how parameters are passed to a subroutine on |
---|
367 | the SPARC. The caller loads values into what are its output |
---|
368 | registers. Then after the callee executes a save instruction, |
---|
369 | those parameters are available in its input registers. This is |
---|
370 | a very efficient way to pass parameters as no data is actually |
---|
371 | moved by the save or restore instructions. |
---|
372 | |
---|
373 | @ifinfo |
---|
374 | @node Calling Conventions Call and Return Mechanism, Calling Conventions Calling Mechanism, Calling Conventions Register Windows, Calling Conventions |
---|
375 | @end ifinfo |
---|
376 | @section Call and Return Mechanism |
---|
377 | |
---|
378 | The SPARC architecture supports a simple yet |
---|
379 | effective call and return mechanism. A subroutine is invoked |
---|
380 | via the call (call) instruction. This instruction places the |
---|
381 | return address in the caller's output register 7 (o7). After |
---|
382 | the callee executes a save instruction, this value is available |
---|
383 | in input register 7 (i7) until the corresponding restore |
---|
384 | instruction is executed. |
---|
385 | |
---|
386 | The callee returns to the caller via a jmp to the |
---|
387 | return address. There is a delay slot following this |
---|
388 | instruction which is commonly used to execute a restore |
---|
389 | instruction -- if a register window was allocated by this |
---|
390 | subroutine. |
---|
391 | |
---|
392 | It is important to note that the SPARC subroutine |
---|
393 | call and return mechanism does not automatically save and |
---|
394 | restore any registers. This is accomplished via the save and |
---|
395 | restore instructions which manage the set of registers windows. |
---|
396 | |
---|
397 | @ifinfo |
---|
398 | @node Calling Conventions Calling Mechanism, Calling Conventions Register Usage, Calling Conventions Call and Return Mechanism, Calling Conventions |
---|
399 | @end ifinfo |
---|
400 | @section Calling Mechanism |
---|
401 | |
---|
402 | All RTEMS directives are invoked using the regular |
---|
403 | SPARC calling convention via the call instruction. |
---|
404 | |
---|
405 | @ifinfo |
---|
406 | @node Calling Conventions Register Usage, Calling Conventions Parameter Passing, Calling Conventions Calling Mechanism, Calling Conventions |
---|
407 | @end ifinfo |
---|
408 | @section Register Usage |
---|
409 | |
---|
410 | As discussed above, the call instruction does not |
---|
411 | automatically save any registers. The save and restore |
---|
412 | instructions are used to allocate and deallocate register |
---|
413 | windows. When a register window is allocated, the new set of |
---|
414 | local registers are available for the exclusive use of the |
---|
415 | subroutine which allocated this register set. |
---|
416 | |
---|
417 | @ifinfo |
---|
418 | @node Calling Conventions Parameter Passing, Calling Conventions User-Provided Routines, Calling Conventions Register Usage, Calling Conventions |
---|
419 | @end ifinfo |
---|
420 | @section Parameter Passing |
---|
421 | |
---|
422 | RTEMS assumes that arguments are placed in the |
---|
423 | caller's output registers with the first argument in output |
---|
424 | register 0 (o0), the second argument in output register 1 (o1), |
---|
425 | and so forth. Until the callee executes a save instruction, the |
---|
426 | parameters are still visible in the output registers. After the |
---|
427 | callee executes a save instruction, the parameters are visible |
---|
428 | in the corresponding input registers. The following pseudo-code |
---|
429 | illustrates the typical sequence used to call a RTEMS directive |
---|
430 | with three (3) arguments: |
---|
431 | |
---|
432 | @example |
---|
433 | load third argument into o2 |
---|
434 | load second argument into o1 |
---|
435 | load first argument into o0 |
---|
436 | invoke directive |
---|
437 | @end example |
---|
438 | |
---|
439 | @ifinfo |
---|
440 | @node Calling Conventions User-Provided Routines, Memory Model, Calling Conventions Parameter Passing, Calling Conventions |
---|
441 | @end ifinfo |
---|
442 | @section User-Provided Routines |
---|
443 | |
---|
444 | All user-provided routines invoked by RTEMS, such as |
---|
445 | user extensions, device drivers, and MPCI routines, must also |
---|
446 | adhere to these calling conventions. |
---|
447 | |
---|