| Allegro CL version 8.2 Minimally revised from 8.1. 8.1 version |
Arguments: name-and-options arglist &key call-direct callback convention returning method-index release-heap release-heap-ignorable arg-checking optimize-for-space strings-convert error-value pass-structs-by-value
This macro creates the specification which allows Lisp to correctly call non-Lisp code. Like other defining forms, its macroexpansion clearly shows what will occur and at what eval-when times. The execution of the expanded form always returns the Lisp name being defined. The definition that is installed is a Lisp function that serves as a wrapper and initiates the foreign call.
Macroexpansion of a def-foreign-call form provides useful information about how the call is interpreted. See below.
The following table shows the arguments. The first two entries are the required arguments and the remainder are keyword arguments.
Argument | Value and Details | Notes |
name-and-options | A required argument.
Symbol or a list of a symbol and an external-name specification, which can either be: (1) a symbol naming a function of one argument that returns a string to be used as the foreign name or (2) a string which will be used as the foreign name. |
The symbol represents the lisp-name
for which the
foreign-call definition will be installed. The external name
specification can be either a string specifying a literal external
name, or it can be a symbol, which represents the name of a
conversion function. That conversion function must take one
required argument and at least the language
keyword argument, and must be defined at the time the macro
expansion is executed. At that time this conversion function will
be called and will receive the lisp-name specified, as well as the
arguments :language lang where lang
is the value of the convention keyword
argument to def-foreign-call. |
arglist | A required argument. A possibly
empty list of
argument specifications. |
nil implies
much the same as it does in C, that arguments are
not checked for type or number.
(:void) means 0 arguments are explicitly required (also as in C). Note that string-conversion is done automatically when
arglist is Otherwise a list of argument specifications. See Note 1: Argument Specifications after the table. See A note on foreign addresses
in foreign-functions.htm
for a discussion of foreign addresses and what is expected
when |
returning |
Keyword argument.
Default: the foreign type The value can also be: A foreign type (defined by def-foreign-type) A list of a foreign type and a Lisp type (and an optional
third element which is not
used but may be in a later release). Example:
|
This argument specifies how the value returned
from the foreign function will be interpreted. If both foreign and
Lisp types are chosen, they will be checked for consistency and a
warning might be given. A common idiom is to use
to specify that the foreign value returned is to be simply shifted into a fixnum value, with no consing and simple truncation of the top two bits on overflow. If |
convention | Keyword argument. Default :c
Other possibilities listed in Note 2: Possible Values for Convention after the table. |
This argument allows the specialization of calling conventions due to language or operating-system distinctions. The default convention is :c, and is adequate for most situations. (Note that on Windows the c/stdcall convention distinction is required for callbacks using defun-foreign-callable, but is not required in def-foreign-call). |
arg-checking | t or
nil (default is t ) |
If true, this argument causes
the Lisp wrapper function to first check the
Lisp types against the Lisp argument type specifications.
When nil , no
argument checking is done (although the number of arguments
might still be checked). If
true, the lisp-types specified or
implied in the argument specification
(provided with the arglist argument)
is used to check the actual arguments to the
wrapper; if a mismatch occurs, error is called. The default
value is t ,
unless arglist is nil . |
call-direct | t or nil
(default is nil ) |
The argument causes no changes to the
Lisp wrapper itself, but, when
specified true, allows for other Lisp functions to call
the foreign function directly when
compiled after the def-foreign-call
form is in effect. In order for the
compilation of a direct-call to be successful, the
argument and return types must imply
simple type conversions which the compiler can handle.
That list of direct-callable
conversions on a platform is constantly changing, but can be
examined by calling the
function list-call-direct-possibilities.
If
for any reason a call to the foreign function cannot be
compiled into a direct-call, a
warning is issued and a call to the wrapper is generated.
When error-value is non- |
method-index [Windows Only] | nil (the default)
or an index into C++ table, as described at
right. |
This argument allows for calling of
C++ style member-methods. The value,
if specified, must be an integer index into the virtual
table of the C++ class. Symbolic
index specifications are not directly supported.
See Note 6: More on the
:method-index argument for information on a
non- |
callback | t (the default and only allowed value) | The callback
keyword is non-operative, but is retained in the
hopes that its functionality can be revived in future versions.
A null value indicates a
promise by the programmer that the foreign function will never
call-back into lisp.
Unfortunately, due to the nature of OS threads implementations,
this promise is currently
impossible to keep. The value of this keyword is always
taken as t , and a
warning is issued if specified to nil . |
release-heap | Only used on platforms that use the :os-threads model for multiprocessing. See Note 3: the release-heap keyword argument below the table. | The
release-heap keyword allows the foreign function
to operate in native-OS threads (so :os-threads is on the *features* list), without
causing conflicting demands on the Lisp heap. The values for this
keyword are discussed in Note 3: the
release-heap keyword argument below the table. Note: the
specification of :release-heap on any non-os-threads implementation to
any value other than :never will generate a
warning, unless the user also specifies :release-heap-ignorable as a
non-nil value.
|
release-heap-ignorable | t or nil (default is nil ) |
This
argument, when t , tells the system to
ignore the release-heap keyword
argument, regardless of its value, on non-os-threads
implementations. The value on non-os-threads implementations
should be :never .
If the value of this argument
is nil , a warning will be generated if
the value of the release-heap is anything
other than :never . (The reason is such a value
is meaningless and the system wants to be sure that the programmer
understands that a meaningless value has been specified. Assuming
that the heap can be released on non-os-threads (it cannot be
released) may affect behavior or performance.) This argument is
provided to allow the same def-foreign-call forms to be
used on both os-threads and non-os-threads platforms without
warnings being signaled and without conditionalizing the value
of the release-heap argument.
|
optimize-for-space | t or nil (default is nil ) |
The optimize-for-space keyword provides for minimal space requirement for foreign-call wrappers. This option is best used in conjunction with the call-direct option. If true, optimize-for-space will ensure that the wrapper definition takes up very little room, usually as a closure. This usually comes at a cost of speed, and so only makes sense when call-direct is used to compile all actual calls to the foreign function directly, so that the Lisp wrapper is not called normally at all. |
strings-convert | t or
nil
(default is t ) |
This argument assists in having the
foreign-function
interface handle Allegro CL's 16-bit strings automatically.
When the strings-convert is true, then
when any of the specified
arguments at def-foreign-call time are declared directly or indirectly
as (* :char) , def-foreign-call augments the
function wrapping the low-level foreign function call so that for each
(* :char) declared argument, a check is made at
runtime to see if that declaration's corresponding value is a string.
If it is, then that value is converted at runtime to native-string
format using a dynamic-extent array, and this new array is passed in
place of the original string argument to low-level foreign function
call. See Foreign-Functions in
iacl.htm for full details and examples.
If arglist is |
error-value | nil ,
:errno , :os-specific ,
(default is nil ) |
nil causes normal operation of the foreign call
and a return of the one value that the foreign call itself
returns.
call-direct is
ineffective if error-value is
non- See Note 5: More on the error-value argument after the table for more information. |
pass-structs-by-value | nil
or t , default is nil
|
nil causes an argument structure not
specified with a * to be passed by reference anyway. So an argument
specification (point Point)
with pass-structs-by-value nil will be passed by
reference, as will (point (* Point)) ,
while (point Point)
with pass-structs-by-value t will be passed by
reference. If not specified, a warning is
issued. See Passing structures by value
in foreign-functions.htm for details.
|
Argument specifications are available with a rich set of syntax and defaults which allow for a C "feel" while still retaining the Lisp semantics and power.
The basic argument list is simply a list of names, e.g. (a b c d), whose types default to C int types converted in the usual manner from Lisp integer types. Any one argument can be specified more fully, as a list of the name optionally followed by the foreign type optionally followed by the Lisp type (optionally followed by a translation specification, which has not been implemented). Here is an example:
(a (b :int fixnum) (c :lisp))
The
foreign type can either be a built-in foreign type or a type defined
by def-foreign-type, or it can be
one of the keywords :lisp
,
:foreign-address
,
or :single-float-no-proto
(deprecated). The value
:lisp means the argument will be passed unchanged, analogous to the
returning type :lisp. The lisp type (the optional third element of
the list) can be any valid lisp type.
If the foreign type is not
specified, it defaults to
:int
(and the Lisp type thus defaults to integer).
If the
foreign type is specified but the Lisp type is not, a reasonable Lisp
type is chosen to correspond to the foreign type. If both foreign and
Lisp types are chosen, they will be checked for consistency and a
warning might be given. A foreign type specification that includes a
reference spec such as (& :int)
will be interpreted
as a pass-by-reference argument.
For boolean values, specify the argument (argname :int
boolean)
. Then any non-nil
Lisp
value (including 0) will be converted into a C value of 1, and nil
will be converted into a C value of 0. For
returned values, a C value of 0 is converted into nil
and a non-zero C value is converted into t
.
The special Lisp type specification :no-proto
is
provided for use with a :float
foreign type; it is
equivalent to the :single-float-no-proto
. Note that
both of these specifications are deprecated though they will
work. The preferred specification is (:double
single-float)
.
Specifying the value (* :float) or (* :double) as the type of an argument is not recommended. The function will expect a foreign address (not a Lisp address) and it will not pass the address of a Lisp float is a Lisp float is given as a value.
See
A note on foreign addresses
in foreign-functions.htm for a discussion of
foreign addresses and what is expected when
:foreign-address
is specified.
Other than :c
, (the default and suitable for most
purposes), the :fortran
convention is defined.
This convention generally causes a conversion of most atomic arguments
to pass-by-reference.
:fastcall
is a special convention used by some
Windows operating systems to speed up some calls, by passing two
arguments in registers. However, it does not work with Allegro CL. In
Allegro CL on X86 architectures, the first two arguments are usually
passed in registers anyway in Lisp, but they are different registers
than used in fastcall. Also, since the calling sequence itself
overshadows the speed that would be gained by saving a couple of push
instructions, the foreign call to a fastcall function would not in
fact be very fast at all.
The native-threads implementation of Allegro CL changes some basic assumptions of the foreign functions user interface. There is always exactly one native thread per Lisp Process, but there is not necessarily a Lisp process for every thread. Threads are free to run whenever they want; however, only one thread at a time can access the Lisp heap (for read or write); a thread cannot access the Lisp heap unless it has "acquired" the heap, which is only possible after another thread has "released" the heap.
See Releasing the heap when calling foreign functions in foreign-functions.htm for more information on this point.
def-foreign-call allows for the specification of whether to release the heap or not during a call. The possibilities for the release-heap keyword argument are:
:never
- This is the default and is compatible to
the original defforeign interface; the caller
necessarily has the lisp heap, this call will not release it. Note
that if the foreign code being called spawns any new threads, or if it
allows another thread to run, and the other thread attempts to call
back into lisp, it will have to wait for the lisp heap. The danger is
that the original thread may be waiting for results from its partner
thread, but it has not yet given up the heap (this constitutes a
deadlock situation). If this situation holds (foreign code does spawn
new thread which call back into Lisp), :when-ok
is
the appropriate value for the release-heap
argument.
:always
- The foreign call always
gives up the heap before making the
transition into non-lisp execution. If the form is being
called within the dynamic context
of a without-interrupts
form, an error
is signaled. :when-ok
- The current dynamic context is
examined, and if
without-interrupts is in effect, the heap is not released;
otherwise the heap is released.
(ff:def-foreign-call foo ())
has no arguments specified, meaning that any number of
arguments of any type
will be passed. If any of these arguments are strings, it may be that
string conversion should be performed.
String conversion is done by default. The
above def-foreign-call form will
generate a warning message (to indicate that string arguments will be
converted). To suppress the warning but still convert the strings,
specify the value t
for the
strings-convert keyword argument. To suppress
the warning and to suppress all automatic strings conversion, specify
the value nil
for the
strings-convert keyword argument.
Getting an error value from a foreign call is somewhat complicated, so users should not casually use this feature, but instead consider whether the information is necessary and be aware of various ways in which the information may be incorrect.
First note the following:
nil
value for
the error-value argument) if there is reason to
believe it may be needed.
nil
value for for
the error-value argument. Foreign function
call are complicated and typically additional functionality is wrapped
around the actual function call by the system (that is, by Allegro
CL). This additional functionality may affect the value of
the errno system variable in the current system thread or the
value returned by GetLastError() so simply looking
at errno or calling GetLastError() after the forreign
call has returned will not work: the value seen can be different from
the correct value. When error-value has an
appropriate non-nil
value (appropriate values
are discussed below), code is added by the system to get and store the
value of errno or the return value of GetLastError()
immediately after the actual foreign function returns (and before the
additional wrapper code is
run). Using error-value is the only way to get
the correct value, and even that may not always work, as the next
bullet discusses.
The two acceptable non-nil
values
for error-value are :errno
and :os-specific
.
The two non-nil
values have the same effect:
the value of errno is stored immediately after the actual
foreign function returns (and before additional wrapper code is
run), and then returned as the second return value of the foreign
call.
The values have different effects.
If you specify the value
:os-specific
, then GetLastError() is called
immediately after the actual foreign function returns (and before
additional wrapper code is run), and then returned as the second
return value of the foreign call. This is the standard Windows
procedure, and works for all standard Windows routines, for
example LoadLibrary() (see the description of that function in
the MSDN where it says that you get error information by
calling GetLastError()).
:errno
, then the value
of errno is stored immediately after the actual foreign
function returns (and before additional wrapper code is run), and then
returned as the second return value of the foreign call. This is not
standard Windows procedure, but is how some routines work,
particularly those which are provided in UNIX-like libraries. This is
often how Windows versions of open() works, for example,
(open() is not a standard Windows function).
On Windows, you must specify the appropriate way to get the error
value for the routine you are
calling. Specifying :errno
will give a wrong value
for LoadLibrary(). Specifying :os-specific
will give a wrong value for (many, perhaps all implementations
of) open().
This argument is supported on Windows only. If a non-nil
value is specified for the
method-index keyword argument, then the value
must be a vector whose first value is the integer index into the
virtual table of the C++ class. And then, when the foreign function
is called, the first argument of the call must be the vector whose
first element is an integer which is a pointer to the table of method
addresses. The arguments specified to def-foreign-call follow that
first argument. Note that the function name specified in the def-foreign-call form
is used only for the Lisp function name, and does not refer to any
function in a shared library. Instead, the function's address (as a
table address and an index into the table) is passed when the function
is called.
def-foreign-call is defined to
default its :returning keyword argument
(specifying the expected type of value returned by the foreign call)
to :int
. :int
corresponds to C's
int type. However, if the foreign function does not actually return an
int, subtle bugs could be introduced in programs, particularly if the
C function returns a long, an unsigned long, or a pointer of some
sort. In 32-bit Lisps, returning those values is not a problem (when
:returning :int
is specified or defaulted to)
because int is always 32 bits on every architecture we support. But on
64-bit Lisps, if a 64 bit value is returned, the upper 32 bits are
lost. If the value was not correctly sign-extended by the foreign
code, a negative value in the foreign code could be seen by Lisp as a
large positive value. Also, the :long
or
:unsigned-long
type is an inadequate specfication
because on Windows long types are always 32 bits. So on either 32 or
64 bit lisps, for portability, use :returning
:unsigned-nat
when the return value is some kind of
pointer. (See The :nat and :unsigned-nat types
in implementation.htm for a description of
the :nat
and :unsigned-nat
types.) When the returned value is an integer value, be sure to use
the correct type and be sure that the foreign code actually produces
that type.
def-foreign-call can accept
:returning :boolean
as a return type, and it will
be automatically translated to a canonical form which is
:returning (:int boolean)
. This works with some
foreign languages (where 0 is considered false and anything else is
considered true - it translates 0 into nil
on
the lisp side and anything else to the value t
), but in some cases (C++, for instance) the boolean
type is equivalent to signed-char type, and so it must be specified in
the def-foreign-call as
:returning (:char boolean)
.
(def-foreign-call add2 (x y))
The symbol add2 will have a function definition calling the foreign function probably named "add2" in C, whose first arg is named "x" and is an integer in Lisp and which is converted to an int for passing to C. If the integer is larger than can be held in a C int, it is truncated. As with the first arg, the second arg named "y" is an integer converted to a C int. The return value is interpreted as a C int type, and is converted to a Lisp integer (which may either be a fixnum or consed as a bignum).
We say the foreign function is "probably" named "add2" because since no specific name or conversion function is specified, the default system conversion function is used. It depends on the platform and platform-specific rules but typically downcases the symbol name.
(def-foreign-call t_double ((x :double) (y :double single-float) (z :int fixnum)) :returning :double)
Call a function, probably named "t_double" in C (again "probably" because the actual name depends on platform-dependent defaults), whose first arg is a double-float both in Lisp and in C, and whose second arg is a single-float in Lisp but is converted to double float for passing into C (this is the calling convention used by some non ANSI C compilers and by others when the arguments are not prototyped), and the third argument is a fixnum Lisp passed as an integer to C. The function returns and boxes a double-float value to Lisp.
(def-foreign-call (t-float dash-to-underscore) ((x :double) (y (:float :no-proto)) (z :int fixnum) (w (* :char) string)) :returning #-(or (and sun4 (not svr4)) sun3q) :float #+(or (and sun4 (not svr4)) sun3q) (:double single-float) (def-foreign-call (t-float "t_float") ((x :double) (y (:float :no-proto)) (z :int fixnum) (w (* :char) string)) :returning #-(or (and sun4 (not svr4)) sun3q) :float #+(or (and sun4 (not svr4)) sun3q) (:double single-float)
These two examples do the same thing: call a function, named "t_float" in C (assuming in the first case proper conversion by dash-to-underscore, which must already be defined and should downcase the symbol name and replace dashes with underscores), whose first arg is a double-float both in Lisp and in C. Like the previous example, the second arg is a float in Lisp, and is converted to double float for passing into C. The third arg named "z" is a fixnum passed as an int, and "w" is a (null-terminated) Lisp string, whose first-character-address is passed to C (beware, the string may move if a gc is allowed). Depending on the architecture, the C function will return either a double (from older C compilers) or a float, each interpreted and boxed as a Lisp single-float value.
We give both examples to show how a lisp name (the symbol
t-float
) is converted to a foreign name
("t_float"). You can either specify a function that takes a
symbol as an argument and returns the correct string (so
(dash-to-underscore 't-float)
returns
"t_float"
) or you can simply specify the
correct string. Note again that dash-to-underscore
must be already defined when the def-foreign-call form is
evaluated.
def-foreign-call has enhanced the macroexpansion to give useful information for users. Here is an example:
cl-user(11): (pprint (macroexpand '(ff:def-foreign-call foo (x (y (* :char)))))) Warning: A runtime with-native-string call is being generated for argument `y' to the foreign-function `foo'. The with-native-string macro can be used for explicit string conversions around the foreign calls. This warning is suppressed when :strings-convert is specified in the def-foreign-call. (progn (eval-when (:compile-toplevel) (excl::check-lock-definitions-compile-time 'foo 'function 'foreign-functions:def-foreign-call (fboundp 'foo)) (push 'foo excl::.functions-defined.)) (eval-when (compile load eval) (remprop 'foo 'system::direct-ff-call)) (setf (fdefinition 'foo) (let ((excl::f (named-function foo (lambda (x y) (excl::check-args '((:int (integer * *)) ((* :char) (array character (*)))) 'foo x y) (with-native-string (#:g34798 (if* (stringp y) then y else "")) (unless (stringp y) (setq #:g34798 y)) (symbol-macrolet ((y #:g34798)) (system::ff-funcall (load-time-value (excl::determine-foreign-address '("foo" :language :c) 2 nil)) '(:int (integer * *)) x '((* :char) (array character (*))) y '(:int (integer * *))))))))) (excl::set-func_name excl::f 'foo) excl::f)) (record-source-file 'foo) 'foo) cl-user(12):
The new array implementation is discussed in the Arrays and short arrays section in implementation.htm. In brief, standard Common Lisp arrays now can be significantly larger than in earlier releases, while the new short arrays implement the old arrays (the same size limitations but also the same type codes and structure).
In this discussion, `array' refers to the newly-implemented arrays, while `short array' refers to the old implementation, preserved as short arrays in 7.0.
Foreign calls are made with arrays as arguments by passing the address of the first value. In the new implementation, simple-arrays always have exactly the same first element offset (but some short arrays are aligned to the next higher word boundary so that the elements within are naturally aligned). This sometimes-difference between arrays and short-arrays poses an extra burden on the ff interface, in that the arrays must be distinguished between themselves at runtime.
It is now possible to declare an argument a
(short-simple-array ... (*))
and the interface will
generate code as it did before for normal arrays, passing the address
of the first argument.
For 7.0, a declaration of (simple-array
... (*))
actually generates code that tests at runtime
whether the argument is a short array or a normal array. So in
effect, a short simple-array passed in as if it were a normal
simple-array will be properly passed.
Note that with this setup, if argument checking is specified and a short-array is passed in, the check will fail, because a short-array is not a subtype of simple-array. But for 7.0, if you suppress this argument checking, the interface will pass either array correctly.
However, programmers are urged to provide correct declarations and
pass the correct type of array even though 7.0 allows
sloppiness. In a future release, we anticipate adding a
(dual-simple-array ... (*))
declaration to the
direct-call foreign interface, and to move that functionality from its
current place in the (simple-array ... (*))
declaration. This would then mean that the (simple-array
... (*))
declaration would only pass simple-arrays, and
not short simple-arrays. This change will also make more
consistent the arg-checking feature of the direct-call interface,
since the dual-simple-array type is defined as an or of simple-array
and short-simple-array, so a short-simple-array being passed will pass
the test of being a dual-simple-array.
See ftype.htm for information on foreign types in Allegro CL and foreign-functions.htm for general information on foreign functions in Allegro CL. See particularly def-foreign-call in foreign-functions.htm.
Copyright (c) 1998-2016, Franz Inc. Oakland, CA., USA. All rights reserved.
This page has had minimal revisions compared to the 8.1 page.
Created 2016.6.21.
| Allegro CL version 8.2 Minimally revised from 8.1. 8.1 version |