1 | @c |
---|
2 | @c COPYRIGHT (c) 1988-1997. |
---|
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 Name, Top |
---|
11 | @end ifinfo |
---|
12 | @chapter Calling Conventions |
---|
13 | @ifinfo |
---|
14 | @menu |
---|
15 | * Calling Conventions Introduction:: |
---|
16 | * Calling Conventions Processor Background:: |
---|
17 | * Calling Conventions Calling Mechanism:: |
---|
18 | * Calling Conventions Register Usage:: |
---|
19 | * Calling Conventions Parameter Passing:: |
---|
20 | * Calling Conventions User-Provided Routines:: |
---|
21 | @end menu |
---|
22 | @end ifinfo |
---|
23 | |
---|
24 | @ifinfo |
---|
25 | @node Calling Conventions Introduction, Calling Conventions Processor Background, Calling Conventions, Calling Conventions |
---|
26 | @end ifinfo |
---|
27 | @section Introduction |
---|
28 | |
---|
29 | Each high-level language compiler generates |
---|
30 | subroutine entry and exit code based upon a set of rules known |
---|
31 | as the compiler's calling convention. These rules address the |
---|
32 | following issues: |
---|
33 | |
---|
34 | @itemize @bullet |
---|
35 | @item register preservation and usage |
---|
36 | |
---|
37 | @item parameter passing |
---|
38 | |
---|
39 | @item call and return mechanism |
---|
40 | @end itemize |
---|
41 | |
---|
42 | A compiler's calling convention is of importance when |
---|
43 | interfacing to subroutines written in another language either |
---|
44 | assembly or high-level. Even when the high-level language and |
---|
45 | target processor are the same, different compilers may use |
---|
46 | different calling conventions. As a result, calling conventions |
---|
47 | are both processor and compiler dependent. |
---|
48 | |
---|
49 | This chapter describes the calling conventions used |
---|
50 | by the GNU C and standard HP-UX compilers for the PA-RISC |
---|
51 | architecture. |
---|
52 | |
---|
53 | @ifinfo |
---|
54 | @node Calling Conventions Processor Background, Calling Conventions Calling Mechanism, Calling Conventions Introduction, Calling Conventions |
---|
55 | @end ifinfo |
---|
56 | @section Processor Background |
---|
57 | |
---|
58 | The PA-RISC architecture supports a simple yet |
---|
59 | effective call and return mechanism for subroutine calls where |
---|
60 | the caller and callee are both in the same address space. The |
---|
61 | compiler will not automatically generate subroutine calls which |
---|
62 | cross address spaces. A subroutine is invoked via the branch |
---|
63 | and link (bl) or the branch and link register (blr). These |
---|
64 | instructions save the return address in a caller specified |
---|
65 | register. By convention, the return address is saved in r2. |
---|
66 | The callee is responsible for maintaining the return address so |
---|
67 | it can return to the correct address. The branch vectored (bv) |
---|
68 | instruction is used to branch to the return address and thus |
---|
69 | return from the subroutine to the caller. It is is important to |
---|
70 | note that the PA-RISC subroutine call and return mechanism does |
---|
71 | not automatically save or restore any registers. It is the |
---|
72 | responsibility of the high-level language compiler to define the |
---|
73 | register preservation and usage convention. |
---|
74 | |
---|
75 | @ifinfo |
---|
76 | @node Calling Conventions Calling Mechanism, Calling Conventions Register Usage, Calling Conventions Processor Background, Calling Conventions |
---|
77 | @end ifinfo |
---|
78 | @section Calling Mechanism |
---|
79 | |
---|
80 | All RTEMS directives are invoked as standard |
---|
81 | subroutines via a bl or a blr instruction with the return address |
---|
82 | assumed to be in r2 and return to the user application via the |
---|
83 | bv instruction. |
---|
84 | |
---|
85 | @ifinfo |
---|
86 | @node Calling Conventions Register Usage, Calling Conventions Parameter Passing, Calling Conventions Calling Mechanism, Calling Conventions |
---|
87 | @end ifinfo |
---|
88 | @section Register Usage |
---|
89 | |
---|
90 | As discussed above, the bl and blr instructions do |
---|
91 | not automatically save any registers. RTEMS uses the registers |
---|
92 | r1, r19 - r26, and r31 as scratch registers. The PA-RISC |
---|
93 | calling convention specifies that the first four (4) arguments |
---|
94 | to subroutines are passed in registers r23 - r26. After the |
---|
95 | arguments have been used, the contents of these registers may be |
---|
96 | altered. Register r31 is the millicode scratch register. |
---|
97 | Millicode is the set of routines which support high-level |
---|
98 | languages on the PA-RISC by providing routines which are either |
---|
99 | too complex or too long for the compiler to generate inline code |
---|
100 | when these operations are needed. For example, indirect calls |
---|
101 | utilize a millicode routine. The scratch registers are not |
---|
102 | preserved by RTEMS directives therefore, the contents of these |
---|
103 | registers should not be assumed upon return from any RTEMS |
---|
104 | directive. |
---|
105 | |
---|
106 | Surprisingly, when using the GNU C compiler at least |
---|
107 | integer multiplies are performed using the floating point |
---|
108 | registers. This is an important optimization because the |
---|
109 | PA-RISC does not have otherwise have hardware for multiplies. |
---|
110 | This has important ramifications in regards to the PA-RISC port |
---|
111 | of RTEMS. On most processors, the floating point unit is |
---|
112 | ignored if the code only performs integer operations. This |
---|
113 | makes it easy for the application developer to predict whether |
---|
114 | or not any particular task will require floating point |
---|
115 | operations. This property is taken advantage of by RTEMS on |
---|
116 | other architectures to minimize the number of times the floating |
---|
117 | point context is saved and restored. However, on the PA-RISC |
---|
118 | architecture, every task is implicitly a floating point task. |
---|
119 | Additionally the state of the floating point unit must be saved |
---|
120 | and restored as part of the interrupt processing because for all |
---|
121 | practical purposes it is impossible to avoid the use of the |
---|
122 | floating point registers. It is unknown if the HP-UX C compiler |
---|
123 | shares this property. |
---|
124 | |
---|
125 | @itemize @code{ } |
---|
126 | @item @b{NOTE}: Later versions of the GNU C has a PA-RISC specific |
---|
127 | option to disable use of the floating point registers. RTEMS |
---|
128 | currently assumes that this option is not turned on. If the use |
---|
129 | of this option sets a built-in define, then it should be |
---|
130 | possible to modify the PA-RISC specific code such that all tasks |
---|
131 | are considered floating point only when this option is not used. |
---|
132 | @end itemize |
---|
133 | |
---|
134 | @ifinfo |
---|
135 | @node Calling Conventions Parameter Passing, Calling Conventions User-Provided Routines, Calling Conventions Register Usage, Calling Conventions |
---|
136 | @end ifinfo |
---|
137 | @section Parameter Passing |
---|
138 | |
---|
139 | RTEMS assumes that the first four (4) arguments are |
---|
140 | placed in the appropriate registers (r26, r25, r24, and r23) |
---|
141 | and, if needed, additional are placed on the current stack |
---|
142 | before the directive is invoked via the bl or blr instruction. |
---|
143 | The first argument is placed in r26, the second is placed in |
---|
144 | r25, and so forth. The following pseudo-code illustrates the |
---|
145 | typical sequence used to call a RTEMS directive with three (3) |
---|
146 | arguments: |
---|
147 | |
---|
148 | |
---|
149 | @example |
---|
150 | set r24 to the third argument |
---|
151 | set r25 to the second argument |
---|
152 | set r26 to the first argument |
---|
153 | invoke directive |
---|
154 | @end example |
---|
155 | |
---|
156 | The stack on the PA-RISC grows upward -- i.e. |
---|
157 | "pushing" onto the stack results in the address in the stack |
---|
158 | pointer becoming numerically larger. By convention, r27 is used |
---|
159 | as the stack pointer. The standard stack frame consists of a |
---|
160 | minimum of sixty-four (64) bytes and is the responsibility of |
---|
161 | the callee to maintain. |
---|
162 | |
---|
163 | @ifinfo |
---|
164 | @node Calling Conventions User-Provided Routines, Memory Model, Calling Conventions Parameter Passing, Calling Conventions |
---|
165 | @end ifinfo |
---|
166 | @section User-Provided Routines |
---|
167 | |
---|
168 | All user-provided routines invoked by RTEMS, such as |
---|
169 | user extensions, device drivers, and MPCI routines, must also |
---|
170 | adhere to these calling conventions. |
---|
171 | |
---|
172 | |
---|
173 | |
---|
174 | |
---|