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 | |
---|
21 | @item parameter passing |
---|
22 | |
---|
23 | @item call and return mechanism |
---|
24 | @end itemize |
---|
25 | |
---|
26 | A compiler's calling convention is of importance when |
---|
27 | interfacing to subroutines written in another language either |
---|
28 | assembly or high-level. Even when the high-level language and |
---|
29 | target processor are the same, different compilers may use |
---|
30 | different calling conventions. As a result, calling conventions |
---|
31 | are both processor and compiler dependent. |
---|
32 | |
---|
33 | @section Processor Background |
---|
34 | |
---|
35 | The i386 architecture supports a simple yet effective |
---|
36 | call and return mechanism. A subroutine is invoked via the call |
---|
37 | (call) instruction. This instruction pushes the return address |
---|
38 | on the stack. The return from subroutine (ret) instruction pops |
---|
39 | the return address off the current stack and transfers control |
---|
40 | to that instruction. It is is important to note that the i386 |
---|
41 | call and return mechanism does not automatically save or restore |
---|
42 | any registers. It is the responsibility of the high-level |
---|
43 | language compiler to define the register preservation and usage |
---|
44 | convention. |
---|
45 | |
---|
46 | @section Calling Mechanism |
---|
47 | |
---|
48 | All RTEMS directives are invoked using a call |
---|
49 | instruction and return to the user application via the ret |
---|
50 | instruction. |
---|
51 | |
---|
52 | @section Register Usage |
---|
53 | |
---|
54 | As discussed above, the call instruction does not |
---|
55 | automatically save any registers. RTEMS uses the registers EAX, |
---|
56 | ECX, and EDX as scratch registers. These registers are not |
---|
57 | preserved by RTEMS directives therefore, the contents of these |
---|
58 | registers should not be assumed upon return from any RTEMS |
---|
59 | directive. |
---|
60 | |
---|
61 | @section Parameter Passing |
---|
62 | |
---|
63 | RTEMS assumes that arguments are placed on the |
---|
64 | current stack before the directive is invoked via the call |
---|
65 | instruction. The first argument is assumed to be closest to the |
---|
66 | return address on the stack. This means that the first argument |
---|
67 | of the C calling sequence is pushed last. The following |
---|
68 | pseudo-code illustrates the typical sequence used to call a |
---|
69 | RTEMS directive with three (3) arguments: |
---|
70 | |
---|
71 | @example |
---|
72 | push third argument |
---|
73 | push second argument |
---|
74 | push first argument |
---|
75 | invoke directive |
---|
76 | remove arguments from the stack |
---|
77 | @end example |
---|
78 | |
---|
79 | The arguments to RTEMS are typically pushed onto the |
---|
80 | stack using a push instruction. These arguments must be removed |
---|
81 | from the stack after control is returned to the caller. This |
---|
82 | removal is typically accomplished by adding the size of the |
---|
83 | argument list in bytes to the stack pointer. |
---|
84 | |
---|
85 | @section User-Provided Routines |
---|
86 | |
---|
87 | All user-provided routines invoked by RTEMS, such as |
---|
88 | user extensions, device drivers, and MPCI routines, must also |
---|
89 | adhere to these calling conventions. |
---|
90 | |
---|