1 | @c |
---|
2 | @c COPYRIGHT (c) 1988-1999. |
---|
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 MC68xxx architecture supports a simple yet |
---|
34 | effective call and return mechanism. A subroutine is invoked |
---|
35 | via the branch to subroutine (@code{XXX}) or the jump to subroutine |
---|
36 | (@code{XXX}) instructions. These instructions push the return address |
---|
37 | on the current stack. The return from subroutine (@code{XXX}) |
---|
38 | instruction pops the return address off the current stack and |
---|
39 | transfers control to that instruction. It is is important to |
---|
40 | note that the XXX call and return mechanism 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 either a @code{XXX} |
---|
48 | or @code{XXX} instruction and return to the user application via the |
---|
49 | @code{XXX} instruction. |
---|
50 | |
---|
51 | @section Register Usage |
---|
52 | |
---|
53 | As discussed above, the @code{XXX} and @code{XXX} instructions do |
---|
54 | not automatically save any registers. RTEMS uses the registers |
---|
55 | @b{D0}, @b{D1}, @b{A0}, and @b{A1} as scratch registers. These registers are |
---|
56 | not preserved by RTEMS directives therefore, the contents of |
---|
57 | these registers should not be assumed upon return from any RTEMS |
---|
58 | directive. |
---|
59 | |
---|
60 | @section Parameter Passing |
---|
61 | |
---|
62 | RTEMS assumes that arguments are placed on the |
---|
63 | current stack before the directive is invoked via the @code{XXX} or @code{XXX} |
---|
64 | instruction. The first argument is assumed to be closest to the |
---|
65 | return address on the stack. This means that the first argument |
---|
66 | of the C calling sequence is pushed last. The following |
---|
67 | pseudo-code illustrates the typical sequence used to call a |
---|
68 | RTEMS directive with three (3) arguments: |
---|
69 | |
---|
70 | @example |
---|
71 | @group |
---|
72 | push third argument |
---|
73 | push second argument |
---|
74 | push first argument |
---|
75 | invoke directive |
---|
76 | remove arguments from the stack |
---|
77 | @end group |
---|
78 | @end example |
---|
79 | |
---|
80 | The arguments to RTEMS are typically pushed onto the |
---|
81 | stack using a move instruction with a pre-decremented stack |
---|
82 | pointer as the destination. These arguments must be removed |
---|
83 | from the stack after control is returned to the caller. This |
---|
84 | removal is typically accomplished by adding the size of the |
---|
85 | argument list in bytes to the current stack pointer. |
---|
86 | |
---|
87 | @section User-Provided Routines |
---|
88 | |
---|
89 | All user-provided routines invoked by RTEMS, such as |
---|
90 | user extensions, device drivers, and MPCI routines, must also |
---|
91 | adhere to these calling conventions. |
---|
92 | |
---|