Anonymous user
Category:Sparkling: Difference between revisions
→Extensibility
m (→Performance) |
|||
Line 100:
== Extensibility ==
Users can write and load native extension functions with the aid of the Sparkling C API. Extension functions must be written in C (or in C++ with external C linkage, or any language that supports C linkage and calling conventions), and they must follow a predefined signature, which makes it possible for the Sparkling virtual machine to call such a function.
<lang C>int native_ext_fn(SpnValue *retVal, int argc, SpnValue *argv, void *context);</lang>
Function arguments are passed in an array of Sparkling value (<tt>SpnValue</tt>) objects, and the return value of a function - as seen by a Sparkling script - should be moved into place using a pointer to another <tt>SpnValue</tt>. The (actual, integer) return value of the native function determines whether the virtual machine continues the execution of a program (zero) or raises a runtime exception (non-zero).
The use of compiled, platform-dependent, native dynamic libraries is a work in progress. It is desired that they be added to the library with support for conditional compilation, in the same way libreadline and libobjc is used by the engine. This would mean that on systems which support dynamic loading and expose a C API, users will be able to benefit from the use of pre-compiled libraries, meanwhile on platforms that do not support dynamic code loading, this feature would not impose an irresolvable dependency, so Sparkling could continue to run on those platforms as well, without the ability to load dynamic libraries.
== Debugging ==
| |||