source: rtems/doc/supplements/i386/callconv.t @ 0660b4f8

4.104.114.84.95
Last change on this file since 0660b4f8 was 0660b4f8, checked in by Joel Sherrill <joel.sherrill@…>, on 11/16/99 at 19:50:56

Changed copyright date to 1999.

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