|
0
|
1 \name{dyncall}
|
|
|
2 \alias{.dyncall}
|
|
|
3 \alias{dyncall}
|
|
|
4 \alias{.dyncall.default}
|
|
|
5 \alias{.dyncall.cdecl}
|
|
|
6 \alias{.dyncall.stdcall}
|
|
|
7 \alias{.dyncall.thiscall}
|
|
|
8 \alias{.dyncall.thiscall.msvc}
|
|
|
9 \alias{.dyncall.thiscall.gcc}
|
|
|
10 \alias{.dyncall.fastcall.msvc}
|
|
|
11 \alias{.dyncall.fastcall.gcc}
|
|
|
12 \alias{signature}
|
|
|
13 \alias{call signature}
|
|
|
14 \alias{type signature}
|
|
|
15 \title{Foreign Function Interface with support for almost all C types}
|
|
|
16 \description{
|
|
|
17 Functions to call pre-compiled code with support for most C argument and return types.
|
|
|
18 }
|
|
|
19 \usage{
|
|
|
20 .dyncall( address, signature, ... , callmode = "default" )
|
|
|
21 .dyncall.default ( address, signature, ... )
|
|
|
22 .dyncall.cdecl ( address, signature, ... )
|
|
|
23 .dyncall.stdcall ( address, signature, ... )
|
|
|
24 .dyncall.thiscall ( address, signature, ... )
|
|
|
25 .dyncall.thiscall.msvc( address, signature, ... )
|
|
|
26 .dyncall.thiscall.gcc ( address, signature, ... )
|
|
|
27 .dyncall.fastcall.msvc( address, signature, ... )
|
|
|
28 .dyncall.fastcall.gcc ( address, signature, ... )
|
|
|
29 }
|
|
|
30 \arguments{
|
|
|
31 \item{address}{external pointer to foreign function.}
|
|
|
32 \item{signature}{character string specifying the \emph{call signature} that describes the foreign function type. See details.}
|
|
|
33 \item{callmode}{character string specifying the \emph{calling convention}. This argument has no effect on most platforms, but on Microsoft Windows 32-Bit Intel/x86 platforms. See details.}
|
|
|
34 \item{...}{arguments to be passed to the foreign function. Arguments are converted from R to C values according to the \emph{call signature}. See details.}
|
|
|
35 }
|
|
|
36 \details{
|
|
|
37 \code{.dyncall} offers a flexible Foreign Function Interface (FFI) for
|
|
|
38 the C language with support for calls to arbitrary pre-compiled
|
|
|
39 C function types at run-time. Almost all C fundamental
|
|
|
40 argument- and return types are supported including extended support for
|
|
|
41 pointers. No limitations is given for arity as well.
|
|
|
42 In addition, on the Microsoft Windows 32-Bit Intel/x86 platform, it supports multiple calling conventions to
|
|
|
43 interoperate with System DLLs.
|
|
|
44 Foreign C function types are specified via plain text \emph{type signatures}.
|
|
|
45 The foreign C function type of the target function is known to the FFI
|
|
|
46 in advance, before preparation of the foreign call via plain text
|
|
|
47 \emph{type signature} information.
|
|
|
48 This has several advantages: R arguments do not need to match exactly.
|
|
|
49 Although R lacks some fundamental C value types, they are supported via
|
|
|
50 coercion at this interface (e.g. C \code{float} and 64-bit integer).
|
|
|
51 Arity and argument type checks help make this interface type-safe
|
|
|
52 to a certain degree and encourage end-users to use interface from
|
|
|
53 the interpreter prompt for rapid application development.
|
|
|
54
|
|
|
55 The foreign function to be called is specified by \code{address}, which is an external pointer that is obtained from \code{\link{.dynsym}} or \code{\link{getNativeSymbolInfo}}.
|
|
|
56
|
|
|
57 \code{signature} is a character string that specifies the formal argument-and-return types of the
|
|
|
58 foreign function using a \emph{call signature} string. It should match the function type of the foreign function given by \code{address},
|
|
|
59 otherwise this can lead to a \strong{fatal R process crash}.
|
|
|
60
|
|
|
61 The calling convention is specified \emph{explicitly} via function \code{.dyncall}
|
|
|
62 using the \code{callmode} argument or \emph{implicitly} by using \code{.dyncall.*}
|
|
|
63 functions. See details below.
|
|
|
64
|
|
|
65 Arguments passed via \code{...} are converted to C according to \code{signature} ; see below for details.
|
|
|
66
|
|
|
67 Given that the \code{signature} matches the foreign function type, the FFI provides a certain level of type-safety to users, when
|
|
|
68 exposing foreign functions via call wrappers such as done in \code{\link{dynbind}} and \code{\link{dynport}}.
|
|
|
69 Several basic argument type-safety checks are done during preparation of the foreign function call:
|
|
|
70 The arity of formals and actual arguments must match and they must be compatible as well.
|
|
|
71 Otherwise, the foreign function call is aborted with an error before risking a fatal system crash.
|
|
|
72 }
|
|
|
73 \value{
|
|
|
74 Functions return the received C return value converted to an R value. See section \sQuote{Call Signature} below for details.
|
|
|
75 }
|
|
|
76 \section{Type Signature}{
|
|
|
77 Type signatures are used by almost all other signature formats (call, library, structure and union signature) and also by the low-level (un)-\code{\link{packing}} functions.
|
|
|
78
|
|
|
79 The following table gives a list of valid type signatures for all supported C types.
|
|
|
80
|
|
|
81 \tabular{clll}{
|
|
|
82 \strong{Type Signature} \tab \strong{C type} \tab \strong{valid R argument types} \tab \strong{R return type}\cr
|
|
|
83 '\code{B}' \tab bool \tab raw,logical,integer,double \tab logical\cr
|
|
|
84 '\code{c}' \tab char \tab raw,logical,integer,double \tab integer\cr
|
|
|
85 '\code{C}' \tab unsigned char \tab raw,logical,integer,double \tab integer\cr
|
|
|
86 '\code{s}' \tab short \tab raw,logical,integer,double \tab integer\cr
|
|
|
87 '\code{S}' \tab unsigned short \tab raw,logical,integer,double \tab integer\cr
|
|
|
88 '\code{i}' \tab int \tab raw,logical,integer,double \tab integer\cr
|
|
|
89 '\code{I}' \tab unsigned int \tab raw,logical,integer,double \tab double\cr
|
|
|
90 '\code{j}' \tab long \tab raw,logical,integer,double \tab double\cr
|
|
|
91 '\code{J}' \tab unsigned long \tab raw,logical,integer,double \tab double\cr
|
|
|
92 '\code{l}' \tab long long \tab raw,logical,integer,double \tab double\cr
|
|
|
93 '\code{L}' \tab unsigned long long \tab raw,logical,integer,double \tab double\cr
|
|
|
94 '\code{f}' \tab float \tab raw,logical,integer,double \tab double\cr
|
|
|
95 '\code{d}' \tab double \tab raw,logical,integer,double \tab double\cr
|
|
|
96 '\code{p}' \tab \emph{C pointer} \tab \emph{any vector},externalptr,NULL \tab externalptr\cr
|
|
|
97 '\code{Z}' \tab char* \tab character,NULL \tab character or NULL\cr
|
|
|
98 '\code{x}' \tab SEXP \tab \emph{any} \tab \emph{any}\cr
|
|
|
99 '\code{v}' \tab void \tab \emph{invalid} \tab NULL\cr
|
|
|
100 '\code{*}' \ldots \tab \emph{C type}* (pointer) \tab \emph{any vector},externalptr,NULL \tab externalptr\cr
|
|
|
101 "\code{*<}" \emph{typename} '\code{>}' \tab \emph{typename}* (pointer) \tab raw,externalptr \tab externalptr\cr
|
|
|
102 }
|
|
|
103
|
|
|
104 The last two rows of the table the above refer to \emph{typed pointer} signatures.
|
|
|
105 If they appear as a return type signature, the external pointer returned is
|
|
|
106 a S3 \code{struct} object. See \code{\link{new.struct}} for details.
|
|
|
107
|
|
|
108 }
|
|
|
109 \section{Call Signatures}{
|
|
|
110 Call Signatures are used by \code{\link{.dyncall}} and \code{\link{new.callback}} to describe foreign C function types.
|
|
|
111 The general form of a call signature is as following:
|
|
|
112
|
|
|
113 \tabular{lll}{
|
|
|
114 (\emph{argument-type})* \tab \code{')'} \tab \emph{return-type} \cr
|
|
|
115 }
|
|
|
116
|
|
|
117 The calling sequence given by the \bold{argument types signature} is specified in direct \emph{left-to-right} order of the formal argument types defined in C.
|
|
|
118 The type signatures are put in sequence without any white space in between.
|
|
|
119 A closing bracket character '\code{)}' marks the end of argument types, followed by a
|
|
|
120 single \bold{return type signature}.
|
|
|
121
|
|
|
122 Derived pointer types can be specified as untyped pointers via \code{'p'}
|
|
|
123 or via prefix \code{'*'} following the underlying base type (e.g. \code{'*d'} for \code{double *})
|
|
|
124 which is more type-safe. For example, this can prevent users from passing a \code{numeric} R atomic as \code{int*} if using \code{'*i'} instead of \code{'p'}.
|
|
|
125
|
|
|
126 Dervied pointer types to aggregate \code{union} or \code{struct} types are
|
|
|
127 supported in combination with the framework for handling foreign data types.
|
|
|
128 See \code{\link{new.struct}} for details. Once a C type is registered,
|
|
|
129 the signature \code{*<}\emph{typename}\code{>} can be used to refer to a pointer to an aggregate C object \emph{type}\code{*}.
|
|
|
130 If typed pointers to aggregate objects are used as a return type and the corresponding type information exists, the returned value can be printed and accessed symbolically.
|
|
|
131
|
|
|
132 Here are some examples of C function prototypes and corresponding call signatures:
|
|
|
133
|
|
|
134 \tabular{rll}{
|
|
|
135 \tab \emph{C Function Prototype} \tab \emph{Call Signature} \cr
|
|
|
136 \code{double} \tab \code{sqrt(double);} \tab \code{"d)d"} \cr
|
|
|
137 \code{double} \tab \code{dnorm(double,double,double,int);} \tab \code{"dddi)d"} \cr
|
|
|
138 \code{void} \tab \code{R_isort(int*,int);} \tab \code{"pi)v"} or \code{"*ii)v"} \cr
|
|
|
139 \code{void} \tab \code{revsort(double*,int*,int);} \tab \code{"ppi)v"} or \code{"*d*ii)v"}\cr
|
|
|
140 \code{int} \tab \code{SDL_PollEvents(SDL_Event *);} \tab \code{"p)i"} or \code{"*<SDL_Event>)i"} \cr
|
|
|
141 \code{SDL_Surface*} \tab \code{SDL_SetVideoMode(int,int,int,int);} \tab \code{"iiii)p"} or \code{"iiii)*<SDL_Surface>"} \cr
|
|
|
142 }
|
|
|
143
|
|
|
144 }
|
|
|
145
|
|
|
146 \section{Calling convention}{
|
|
|
147 Calling Conventions specify \sQuote{how} sub-routine calls are performed, and, \sQuote{how} arguments and results are passed,
|
|
|
148 on machine-level. They differ significantly among families of CPU Architectures
|
|
|
149 as well as OS and Compiler implementations.
|
|
|
150
|
|
|
151 On most platforms, a single \code{"default"} C Calling Convention is used.
|
|
|
152 As an exception, on the Microsoft Windows 32-Bit Intel/x86 platform several calling conventions are common.
|
|
|
153 Most of the C libraries still use a \code{"default"} C ( also known as \code{"cdecl"} )
|
|
|
154 calling convention, but when working with Microsoft System APIs and DLLs, the \code{"stdcall"}
|
|
|
155 calling convention must be used.
|
|
|
156
|
|
|
157 It follows a description of supported Win32 Calling Conventions:
|
|
|
158
|
|
|
159 \describe{
|
|
|
160 \item{\code{"cdecl"}}{Dummy alias to \emph{default}}
|
|
|
161 \item{\code{"stdcall"}}{C functions with \emph{stdcall} calling convention. Useful for all Microsoft Windows System Libraries (e.g. KERNEL32.DLL, USER32.DLL, OPENGL32.DLL ...). Third-party libraries usually prefer the default C \emph{cdecl} calling convention. }
|
|
|
162 \item{\code{"fastcall.msvc"}}{C functions with \emph{fastcall} calling convention compiled with Microsoft Visual C++ Compiler. Very rare usage.}
|
|
|
163 \item{\code{"fastcall.gcc"}}{C functions with \emph{fastcall} calling convention compiled with GNU C Compiler. Very rare usage.}
|
|
|
164 \item{\code{"thiscall"}}{C++ member functions.}
|
|
|
165 \item{\code{"thiscall.gcc"}}{C++ member functions compiled with GNU C Compiler.}
|
|
|
166 \item{\code{"thiscall.msvc"}}{C++ member functions compiled with Microsoft Visual C++ Compiler.}
|
|
|
167 }
|
|
|
168
|
|
|
169 As of the current version of this package and for practical reasons, the \code{callmode} argument does not have an effect on almost
|
|
|
170 all platforms, except that if R is running on Microsoft Windows 32-Bit Intel/x86 platform, \code{.dyncall} uses the specified calling convention.
|
|
|
171 For example, when loading OpenGL across platforms, \code{"stdcall"} should be used instead of \code{"default"},
|
|
|
172 because on Windows, OpenGL is a System DLL. This is very exceptional, as in most other cases, \code{"default"} (or \code{"cdecl"}, the alias) need to be used
|
|
|
173 for normal C shared libraries on Windows.
|
|
|
174
|
|
|
175 At this stage of development, support for C++ calls should be considered experimental.
|
|
|
176 Support for Fortran is planed but not yet implemented in dyncall.
|
|
|
177 }
|
|
|
178 \section{Portability}{
|
|
|
179 The implementation is based on the \emph{dyncall} library (part of the DynCall project).
|
|
|
180
|
|
|
181 The following processor architectures are supported: X86 32- and 64-bit, ARM v4t-v7 oabi/eabi (aapcs) and armhf including support for Thumb ISA, PowerPC 32-bit, MIPS 32- and 64-Bit, SPARC 32- and 64-bit; The library
|
|
|
182 has been built and tested to work on various OSs: Linux, Mac OS X, Windows 32/64-bit, BSDs, Haiku, Nexenta/Open Solaris, Solaris, Minix and Plan9,
|
|
|
183 as well as embedded platforms such as Linux/ARM (OpenMoko, Beagleboard, Gumstix, Efika MX, Raspberry Pi), Nintendo DS (ARM), Sony Playstation Portable (MIPS 32-bit/eabi) and iOS (ARM - armv6 mode ok, armv7 unstable).
|
|
|
184 In the context of R, dyncall has currently no support for PowerPC 64-Bit.
|
|
|
185 }
|
|
|
186 \note{
|
|
|
187 The target address, calling convention and call signature \strong{MUST} match foreign function type, otherwise the invocation could lead to a \strong{fatal R process crash}.
|
|
|
188 }
|
|
|
189 \examples{
|
|
|
190 \donttest{
|
|
|
191 mathlib <- dynfind(c("msvcrt","m","m.so.6"))
|
|
|
192 x <- .dynsym(mathlib,"sqrt")
|
|
|
193 .dyncall(x, "d)d", 144L)
|
|
|
194 }
|
|
|
195 }
|
|
|
196 \references{
|
|
|
197 Adler, D. (2012) \dQuote{Foreign Library Interface}, \emph{The R Journal}, \bold{4(1)}, 30--40, June 2012.
|
|
|
198 \url{http://journal.r-project.org/archive/2012-1/RJournal_2012-1_Adler.pdf}
|
|
|
199
|
|
|
200 Adler, D., Philipp, T. (2008) \emph{DynCall Project}.
|
|
|
201 \url{http://dyncall.org}
|
|
|
202 }
|
|
|
203 \seealso{
|
|
|
204 \code{\link{.dynsym}} and \code{\link[base]{getNativeSymbolInfo}} for resolving symbols,
|
|
|
205 \code{\link{dynbind}} for binding several foreign functions via thin call wrappers,
|
|
|
206 \code{\link[base]{.C}} for the traditional FFI to C.
|
|
|
207 }
|
|
|
208 \keyword{programming}
|
|
|
209 \keyword{interface}
|
