0
|
1 %//////////////////////////////////////////////////////////////////////////////
|
|
2 %
|
|
3 % Copyright (c) 2007,2009 Daniel Adler <dadler@uni-goettingen.de>,
|
|
4 % Tassilo Philipp <tphilipp@potion-studios.com>
|
|
5 %
|
|
6 % Permission to use, copy, modify, and distribute this software for any
|
|
7 % purpose with or without fee is hereby granted, provided that the above
|
|
8 % copyright notice and this permission notice appear in all copies.
|
|
9 %
|
|
10 % THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
|
|
11 % WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
|
|
12 % MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
|
|
13 % ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
|
|
14 % WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
|
|
15 % ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
|
|
16 % OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
|
|
17 %
|
|
18 %//////////////////////////////////////////////////////////////////////////////
|
|
19
|
|
20 \newpage
|
|
21 \section{Motivation}
|
|
22
|
|
23 Interoperability between programming languages is a desirable feature
|
|
24 in complex software systems. While functions in scripting languages and virtual machine
|
|
25 languages can be called in a dynamic manner, statically compiled programming
|
|
26 languages such as C, C++ and Objective-C lack this ability.\\
|
|
27 The majority of systems use C function interfaces as their system-level
|
|
28 interface. Calling these (foreign) functions from within a dynamic environment
|
|
29 often involves the development of so called "glue code" on both sides,
|
|
30 the use of external tools generating communication code, or integration
|
|
31 of other middleware fulfilling that purpose. However, even inside a completely
|
|
32 static environment, without having to bridge multiple languages, it
|
|
33 can be very useful to call functions dynamically. Consider, for example, message
|
|
34 systems, dynamic function call dispatch mechanisms, without even knowing about the
|
|
35 target.\\
|
|
36
|
|
37 The \product{dyncall} library project provides a clean and portable C interface
|
|
38 to dynamically issue calls to foreign code using small call kernels written in
|
|
39 assembly. Instead of providing code for every bridged function call, which
|
|
40 unnecessarily results in code bloat, only a modest number of instructions are used
|
|
41 to invoke all the calls.\\
|
|
42
|
|
43 \subsection{Static function calls in C}
|
|
44
|
|
45 The C programming language and its direct derivatives are limited in the way
|
|
46 function calls are handled. A C compiler regards a function call as a
|
|
47 fully qualified atomic operation. In such a statically typed environment, this
|
|
48 includes the function call's argument arity and type, as well as the
|
|
49 return type.\\
|
|
50
|
|
51
|
|
52 \subsection{Anatomy of machine-level calls}
|
|
53
|
|
54 The process of calling a function on the machine level yields a common pattern:
|
|
55
|
|
56 \begin{enumerate}
|
|
57 \item The target function's calling convention dictates how the stack is
|
|
58 prepared, arguments are passed, results are returned and how to clean up
|
|
59 afterwards.
|
|
60 \item Function call arguments are loaded in registers and on the stack according
|
|
61 to the calling convention that take alignment constraints into account.
|
|
62 \item Control flow transfer from caller to callee.
|
|
63 \item Process return value, if any. Some calling conventions specify that
|
|
64 the caller is responsible for cleaning up the argument stack.
|
|
65 \end{enumerate}
|
|
66
|
|
67
|
|
68 \newpage
|
|
69
|
|
70 %\paragraph{Example}
|
|
71 The following example depicts a C source and the corresponding assembly for the X86 32-bit processor architecture.
|
|
72
|
|
73
|
|
74 \begin{lstlisting}[label=cfuncall,caption=C function call,language=C]
|
|
75 extern void f(int x, double y,float z);
|
|
76 void caller()
|
|
77 {
|
|
78 f(1,2.0,3.0f);
|
|
79 }
|
|
80 \end{lstlisting}
|
|
81
|
|
82
|
|
83 \begin{lstlisting}[label=x86asm,caption=Assembly X86 32-bit function call,language={[x86masm]Assembler}]
|
|
84 .global f ; external symbol 'f'
|
|
85 caller:
|
|
86 push 40400000H ; 3.0f (32 bit float)
|
|
87 ; 2.0 (64 bit float)
|
|
88 push 40000000H ; low DWORD
|
|
89 push 0H ; high DWORD
|
|
90 push 1H ; 1 (32 bit integer)
|
|
91 call f ; call 'f'
|
|
92 add esp, 16 ; cleanup stack
|
|
93 \end{lstlisting}
|
|
94
|
|
95
|
|
96 \begin{comment}
|
|
97
|
|
98 Due to the statically compiled nature of the
|
|
99 language itself, the abstraction to the underlying hardware machine
|
|
100 These languages make an abstraction to the machine in a way, where a function
|
|
101 call is an atomic operation that has to be fully qualified at compilation time.
|
|
102
|
|
103 This library follows the approach to abstract the construction of a function call
|
|
104 and provides a small and clean implementation that is extendable by ports to
|
|
105 compilers, operating-systems and processor architectures.
|
|
106 The library solely uses a small kernel function to perform the actual call and
|
|
107 does not require just-in-time code generation.
|
|
108
|
|
109 General-purpose programming languages such as C\footnote{and derived programming
|
|
110 languages such as C++ and Objective-C} are powerful statically compiled
|
|
111 programming languages that allow to implement low-level tasks. They abstract
|
|
112 the underlying hardware to a degree where one is allowed to write functions
|
|
113 that implement algorithms. At the same time, this
|
|
114
|
|
115 Although C is very powerful and a portable language to implement time-critical
|
|
116 and performance greedy application - it is limited in the way it handles calls
|
|
117 to functions.
|
|
118
|
|
119 General-purpose programming languages such as C and C++ are limited in the way
|
|
120 function calls are handled. These languages make an abstraction to the
|
|
121 underlying hardware architecture, so that writing algorithms can be done in a
|
|
122 portable way. While C is quite flexible in case of pointer arithmetics and
|
|
123 I/O in main memory, the flexibility ends at the function call.
|
|
124
|
|
125 In contrast to implementing algorithms, the function call in C is something
|
|
126 that is black-box to the language.
|
|
127
|
|
128 One can either fully bind and call a function at once or none at all.
|
|
129
|
|
130 construct a half-baked function-call without providing C code that performs a particular desired function call
|
|
131 in regard to arity, argument type list, return type and calling convention.
|
|
132 The compiler requires exact information about the desired calling convention,
|
|
133 arity, argument- and return types.
|
|
134 \end{comment}
|
|
135
|