The dyncall library encapsulates architecture-, OS- and compiler-specific function call semantics in a virtual bind argument parameters from left to right and then call interface allowing programmers to call C functions in a completely dynamic manner. In other words, instead of calling a function directly, the dyncall library provides a mechanism to push the function parameters manually and to issue the call afterwards.
Since the idea behind this concept is similar to call dispatching mechanisms of virtual machines, the object that can be dynamically loaded with arguments, and then used to actually invoke the call, is called CallVM. It is possible to change the calling convention used by the CallVM at run-time. Due to the fact that nearly every platform comes with one or more distinct calling conventions, the dyncall library project intends to be a portable and open-source approach to the variety of compiler-specific binary interfaces, platform specific subtleties, and so on…

The core of the library consists of dynamic implementations of different calling conventions written in assembler. Although the library aims to be highly portable, some assembler code needs to be written for nearly every platform/compiler/OS combination. Unfortunately, there are architectures we just don’t have at home or work. If you want to see dyncall running on such a platform, feel free to send in code and patches, or even to donate hardware you don’t need anymore. Check the supported platforms section for an overview of the supported platforms and the different calling convention sections for details about the support.



Foreign function call in C

This section demonstrates how the foreign function call is issued without, and then with, the help of the dyncall library and scripting language bindings.

double call_as_sqrt(void* funptr, double x) 
  return ( ( double (*)(double) )funptr)(x); 
Listing 3: Foreign function call in C
Dyncall C library example

The same operation can be broken down into atomic pieces (specify calling convention, binding arguments, invoking the call) using the dyncall library.

#include <dyncall.h> 
double call_as_sqrt(void* funptr, double x) 
  double r; 
  DCCallVM* vm = dcNewCallVM(4096); 
  dcMode(vm, DC_CALL_C_DEFAULT); 
  dcArgDouble(vm, x); 
  r = dcCallDouble(vm, funptr); 
  return r; 
Listing 4: Dyncall C library example

As you can see, this is more code after all, but completely dynamic. And definitely less than generated glue-code for each function call, if used correctly.

The following are examples from script bindings: Python example

import pydc 
def call_as_sqrt(funptr,x): 
  return,"d)d", x)
Listing 5: Dyncall Python bindings example
R example <- function(funptr,x)  .dyncall(funptr,"d)d", x)
Listing 6: Dyncall R bindings example

Supported platforms/architectures

The feature matrix below gives a brief overview of the currently supported platforms. Different colors are used, where a green cell indicates a supported platform, yellow a platform that might work (but is untested) and red a platform that is currently unsupported. Gray cells are combinations that don’t exist at the time of writing, or that are not taken into account.
Light green cells mark complete feature support, as in dyncall and dyncallback. Dark green means basic support but lacking features (e.g. dyncall support, but not dyncallback). Please note that a green cell (even a light-green one) doesn’t imply that all existing calling conventions/features/build tools are supported for that platform (but the most important). For detailed info about a platform’s support consult the calling convention appendix.

                       |   |  |   |     |     |   |   |  |   |   |   |  |   |   |  |   |
                       |   |  |   |     |     |   |   |  |   |   |   |  |   |   |  |   |
                       |   |  |   |     |     |   |   |  |   |   |   |  |   |   |  |   |
                       |   |  |   |     |     |   |   |  |   |   |   |  |   |   |  |   |
                       | AlphaARMARM64MIPS   MIPS64SuperPHoweProPwCermP6C86k4m88kx86 x64 ItaniSuPmARCSPARCR6I4SC-V
                       |   |  |   | EB| EL| EB| EL|   |   |  |   |   |   |  |   |   |  |   |
                 Linux  ----------------------------------|-----------------------------|
 macOS  / iOS / Darwin  ----------------------------------|-----------------------------|
              FreeBSD   ----------------------------------|-----------------------------|
              NetBSD   ----------------------------------|-----------------------------|
             OpenBSD   ----------------------------------|-----------------------------|
        DragonFlyBSD   ----------------------------------|-----------------------------|
       Solaris / SunOS  ----------------------------------|-----------------------------|
        Plan 9 / 9front ----------------------------------|-----------------------------|
         Haiku / BeOS  ----------------------------------|-----------------------------|
                 Minix  ----------------------------------|-----------------------------|
    Playstation Portable  ----------------------------------|-----------------------------|
          Nintendo DS  ----------------------------------|-----------------------------|
Table 1: Supported platforms

Build Requirements

The library needs at least a c99 compiler with additional support for anonymous structs/unions (which were introduced officially in c11). Given that those are generally supported by pretty much all major c99 conforming compilers (as default extension), it should build fine with a c99 toolchain.