source: rtems/doc/supplements/mips64orion/callconv.t @ f48b1000
Last change on this file since f48b1000 was f48b1000, checked in by Joel Sherrill <joel.sherrill@…>, on Nov 23, 1998 at 10:09:47 PM

New files copied from template and personalized.

  • Property mode set to 100644
File size: 3.1 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.
31@section Processor Background
33The MC68xxx architecture supports a simple yet
34effective call and return mechanism.  A subroutine is invoked
35via the branch to subroutine (@code{XXX}) or the jump to subroutine
36(@code{XXX}) instructions.  These instructions push the return address
37on the current stack.  The return from subroutine (@code{XXX})
38instruction pops the return address off the current stack and
39transfers control to that instruction.  It is is important to
40note that the XXX call and return mechanism does not
41automatically save or restore any registers.  It is the
42responsibility of the high-level language compiler to define the
43register preservation and usage convention.
45@section Calling Mechanism
47All RTEMS directives are invoked using either a @code{XXX}
48or @code{XXX} instruction and return to the user application via the
49@code{XXX} instruction.
51@section Register Usage
53As discussed above, the @code{XXX} and @code{XXX} instructions do
54not automatically save any registers.  RTEMS uses the registers
55@b{D0}, @b{D1}, @b{A0}, and @b{A1} as scratch registers.  These registers are
56not preserved by RTEMS directives therefore, the contents of
57these registers should not be assumed upon return from any RTEMS
60@section Parameter Passing
62RTEMS assumes that arguments are placed on the
63current stack before the directive is invoked via the @code{XXX} or @code{XXX}
64instruction.  The first argument is assumed to be closest to the
65return address on the stack.  This means that the first argument
66of the C calling sequence is pushed last.  The following
67pseudo-code illustrates the typical sequence used to call a
68RTEMS directive with three (3) arguments:
72push third argument
73push second argument
74push first argument
75invoke directive
76remove arguments from the stack
77@end group
78@end example
80The arguments to RTEMS are typically pushed onto the
81stack using a move instruction with a pre-decremented stack
82pointer as the destination.  These arguments must be removed
83from the stack after control is returned to the caller.  This
84removal is typically accomplished by adding the size of the
85argument list in bytes to the current stack pointer.
87@section User-Provided Routines
89All user-provided routines invoked by RTEMS, such as
90user extensions, device drivers, and MPCI routines, must also
91adhere to these calling conventions.
Note: See TracBrowser for help on using the repository browser.