view doc/Description.txt @ 166:d5705f226298

- added portasm support for adding .section .note.GNU-stack "hints" marking generated .o files from assembly files as not needing an executable stack * needed to be done manually in assembly files, in contrast to C translation units where gcc adds such hints automatically * this is for security, and better/easier integration of dyncall into other projects and builds, as dyncall doesn't need an executable stack * thanks to Thorsten Behrens for bringing this up to our intention and providing a first analysis * currently only done on Linux, but will be added across other platforms (where applicable) after some testing
author cslag
date Thu, 05 Jan 2017 11:07:29 +0100
parents 3e629dc19168
children
line wrap: on
line source

DynCall Project

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.
This means, that a program can determine at runtime what function to call, and what parameters to pass to it. The library is written in C and assembly and provides a very simple C interface to program against.

The library comes in very handy to power flexible message systems, dynamic function call dispatch mechanisms, closure implementations or even to bridge different programming languages.
When it comes to language bindings, the dyncall library provides a clean and portable C interface to dynamically issue calls to foreign code using small call kernels written in assembly. Instead of providing code for every bridged function call, which unnecessarily results in code bloat, only a couple of instructions are used to invoke every possible call.