1 | @c |
---|
2 | @c COPYRIGHT (c) 1988-2002. |
---|
3 | @c On-Line Applications Research Corporation (OAR). |
---|
4 | @c All rights reserved. |
---|
5 | @c |
---|
6 | @c $Id$ |
---|
7 | @c |
---|
8 | |
---|
9 | @chapter Calling Conventions |
---|
10 | |
---|
11 | @section Introduction |
---|
12 | |
---|
13 | Each high-level language compiler generates |
---|
14 | subroutine entry and exit code based upon a set of rules known |
---|
15 | as the compiler's calling convention. These rules address the |
---|
16 | following issues: |
---|
17 | |
---|
18 | @itemize @bullet |
---|
19 | @item register preservation and usage |
---|
20 | @item parameter passing |
---|
21 | @item call and return mechanism |
---|
22 | @end itemize |
---|
23 | |
---|
24 | A compiler's calling convention is of importance when |
---|
25 | interfacing to subroutines written in another language either |
---|
26 | assembly or high-level. Even when the high-level language and |
---|
27 | target processor are the same, different compilers may use |
---|
28 | different calling conventions. As a result, calling conventions |
---|
29 | are both processor and compiler dependent. |
---|
30 | |
---|
31 | @section Processor Background |
---|
32 | |
---|
33 | The ARM architecture supports a simple yet |
---|
34 | effective call and return mechanism. A subroutine is invoked |
---|
35 | via the branch and link (@code{bl}) instruction. This instruction |
---|
36 | saves the return address in the @code{lr} register. Returning |
---|
37 | from a subroutine only requires that the return address be |
---|
38 | moved into the program counter (@code{pc}), possibly with |
---|
39 | an offset. It is is important to |
---|
40 | note that the @code{bl} instruction does not |
---|
41 | automatically save or restore any registers. It is the |
---|
42 | responsibility of the high-level language compiler to define the |
---|
43 | register preservation and usage convention. |
---|
44 | |
---|
45 | @section Calling Mechanism |
---|
46 | |
---|
47 | All RTEMS directives are invoked using the @code{bl} |
---|
48 | instruction and return to the user application via the |
---|
49 | mechanism described above. |
---|
50 | |
---|
51 | @section Register Usage |
---|
52 | |
---|
53 | As discussed above, the ARM's call and return mechanism dos |
---|
54 | not automatically save any registers. RTEMS uses the registers |
---|
55 | @code{r0}, @code{r1}, @code{r2}, and @code{r3} as scratch registers and |
---|
56 | per ARM calling convention, the @code{lr} register is altered |
---|
57 | as well. These registers are not preserved by RTEMS directives |
---|
58 | therefore, the contents of these registers should not be assumed |
---|
59 | upon return from any RTEMS directive. |
---|
60 | |
---|
61 | @section Parameter Passing |
---|
62 | |
---|
63 | RTEMS assumes that ARM calling conventions are followed and that |
---|
64 | the first four arguments are placed in registers @code{r0} through |
---|
65 | @code{r3}. If there are more arguments, than that, then they |
---|
66 | are place on the stack. |
---|
67 | |
---|
68 | @section User-Provided Routines |
---|
69 | |
---|
70 | All user-provided routines invoked by RTEMS, such as |
---|
71 | user extensions, device drivers, and MPCI routines, must also |
---|
72 | adhere to these calling conventions. |
---|
73 | |
---|