source: rtems/doc/supplements/sh/callconv.texi @ fad4de2b
Last change on this file since fad4de2b was fad4de2b, checked in by Joel Sherrill <joel.sherrill@…>, on Mar 26, 1998 at 8:47:42 PM

New file. Basically m68k version with Hitachi SH comments thrown in.

  • Property mode set to 100644
File size: 3.4 KB
2@c  COPYRIGHT (c) 1988-1998.
3@c  On-Line Applications Research Corporation (OAR).
4@c  All rights reserved.
6@c  $Id$
9@chapter Calling Conventions
11@section Introduction
13Each high-level language compiler generates
14subroutine entry and exit code based upon a set of rules known
15as the compiler's calling convention.   These rules address the
16following issues:
18@itemize @bullet
19@item register preservation and usage
20@item parameter passing
21@item call and return mechanism
22@end itemize
24A compiler's calling convention is of importance when
25interfacing to subroutines written in another language either
26assembly or high-level.  Even when the high-level language and
27target processor are the same, different compilers may use
28different calling conventions.  As a result, calling conventions
29are both processor and compiler dependent.
31The Hitachi SH architecture supports a simple yet
32effective call and return mechanism.  A subroutine is invoked
33via the branch to subroutine (XXX) or the jump to subroutine
34(XXX) instructions.  These instructions push the return address
35on the current stack.  The return from subroutine (rts)
36instruction pops the return address off the current stack and
37transfers control to that instruction.  It is is important to
38note that the MC68xxx call and return mechanism does not
39automatically save or restore any registers.  It is the
40responsibility of the high-level language compiler to define the
41register preservation and usage convention.
43@section Calling Mechanism
45All RTEMS directives are invoked using either a bsr
46or jsr instruction and return to the user application via the
47rts instruction.
49@section Register Usage
51As discussed above, the bsr and jsr instructions do
52not automatically save any registers.  RTEMS uses the registers
53D0, D1, A0, and A1 as scratch registers.  These registers are
54not preserved by RTEMS directives therefore, the contents of
55these registers should not be assumed upon return from any RTEMS
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
70@section Parameter Passing
72RTEMS assumes that arguments are placed on the
73current stack before the directive is invoked via the bsr or jsr
74instruction.  The first argument is assumed to be closest to the
75return address on the stack.  This means that the first argument
76of the C calling sequence is pushed last.  The following
77pseudo-code illustrates the typical sequence used to call a
78RTEMS directive with three (3) arguments:
82push third argument
83push second argument
84push first argument
85invoke directive
86remove arguments from the stack
87@end group
88@end example
90The arguments to RTEMS are typically pushed onto the
91stack using a move instruction with a pre-decremented stack
92pointer as the destination.  These arguments must be removed
93from the stack after control is returned to the caller.  This
94removal is typically accomplished by adding the size of the
95argument list in bytes to the current stack pointer.
97@section User-Provided Routines
99All user-provided routines invoked by RTEMS, such as
100user extensions, device drivers, and MPCI routines, must also
101adhere to these calling conventions.
Note: See TracBrowser for help on using the repository browser.