Mercurial > pub > dyncall > bindings

comparison R/rdyncall/man/dyncall.Rd @ 0:0cfcc391201f

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
initial from svn dyncall-1745
author Daniel Adler
date Thu, 19 Mar 2015 22:26:28 +0100
parents
children
comparison
equal deleted inserted replaced
-1:000000000000 0:0cfcc391201f
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}