1 |
1026 |
ivang |
@c
|
2 |
|
|
@c COPYRIGHT (c) 1988-2002.
|
3 |
|
|
@c On-Line Applications Research Corporation (OAR).
|
4 |
|
|
@c All rights reserved.
|
5 |
|
|
@c
|
6 |
|
|
@c callconv.t,v 1.3 2002/01/17 21:47:46 joel Exp
|
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 |
|
|
The Hitachi SH architecture supports a simple yet
|
32 |
|
|
effective call and return mechanism. A subroutine is invoked
|
33 |
|
|
via the branch to subroutine (XXX) or the jump to subroutine
|
34 |
|
|
(XXX) instructions. These instructions push the return address
|
35 |
|
|
on the current stack. The return from subroutine (rts)
|
36 |
|
|
instruction pops the return address off the current stack and
|
37 |
|
|
transfers control to that instruction. It is is important to
|
38 |
|
|
note that the MC68xxx call and return mechanism does not
|
39 |
|
|
automatically save or restore any registers. It is the
|
40 |
|
|
responsibility of the high-level language compiler to define the
|
41 |
|
|
register preservation and usage convention.
|
42 |
|
|
|
43 |
|
|
@section Calling Mechanism
|
44 |
|
|
|
45 |
|
|
All RTEMS directives are invoked using either a bsr
|
46 |
|
|
or jsr instruction and return to the user application via the
|
47 |
|
|
rts instruction.
|
48 |
|
|
|
49 |
|
|
@section Register Usage
|
50 |
|
|
|
51 |
|
|
As discussed above, the bsr and jsr instructions do
|
52 |
|
|
not automatically save any registers. RTEMS uses the registers
|
53 |
|
|
D0, D1, A0, and A1 as scratch registers. These registers are
|
54 |
|
|
not preserved by RTEMS directives therefore, the contents of
|
55 |
|
|
these registers should not be assumed upon return from any RTEMS
|
56 |
|
|
directive.
|
57 |
|
|
|
58 |
|
|
|
59 |
|
|
> > The SH1 has 16 general registers (r0..r15)
|
60 |
|
|
> > r0..r3 used as general volatile registers
|
61 |
|
|
> > r4..r7 used to pass up to 4 arguments to functions, arguments above 4 are
|
62 |
|
|
> > passed via the stack)
|
63 |
|
|
> > r8..13 caller saved registers (i.e. push them to the stack if you need them
|
64 |
|
|
> > inside of a function)
|
65 |
|
|
> > r14 frame pointer
|
66 |
|
|
> > r15 stack pointer
|
67 |
|
|
>
|
68 |
|
|
|
69 |
|
|
|
70 |
|
|
@section Parameter Passing
|
71 |
|
|
|
72 |
|
|
RTEMS assumes that arguments are placed on the
|
73 |
|
|
current stack before the directive is invoked via the bsr or jsr
|
74 |
|
|
instruction. The first argument is assumed to be closest to the
|
75 |
|
|
return address on the stack. This means that the first argument
|
76 |
|
|
of the C calling sequence is pushed last. The following
|
77 |
|
|
pseudo-code illustrates the typical sequence used to call a
|
78 |
|
|
RTEMS directive with three (3) arguments:
|
79 |
|
|
|
80 |
|
|
@example
|
81 |
|
|
@group
|
82 |
|
|
push third argument
|
83 |
|
|
push second argument
|
84 |
|
|
push first argument
|
85 |
|
|
invoke directive
|
86 |
|
|
remove arguments from the stack
|
87 |
|
|
@end group
|
88 |
|
|
@end example
|
89 |
|
|
|
90 |
|
|
The arguments to RTEMS are typically pushed onto the
|
91 |
|
|
stack using a move instruction with a pre-decremented stack
|
92 |
|
|
pointer as the destination. These arguments must be removed
|
93 |
|
|
from the stack after control is returned to the caller. This
|
94 |
|
|
removal is typically accomplished by adding the size of the
|
95 |
|
|
argument list in bytes to the current stack pointer.
|
96 |
|
|
|
97 |
|
|
@section User-Provided Routines
|
98 |
|
|
|
99 |
|
|
All user-provided routines invoked by RTEMS, such as
|
100 |
|
|
user extensions, device drivers, and MPCI routines, must also
|
101 |
|
|
adhere to these calling conventions.
|
102 |
|
|
|