Custom Forth Interpreter and External Libraries

I’ve built a basic forth interpreter (it compiles to a basic byte code which gets executed by a vm). Im trying to add support for external functions, but my current solution is to include them in the VM. I’d rather be able to load from some library, what are you all doing?

If it makes any sense, I have the ability for C code to be called from forth but it’s all in one big binary (the VM), how do you all split this up?

Posted in: s/FORTH

🚀 throf

2025-05-30 · 11 months ago · 👍 norayr

1 Comment

👽 spc476 · 2025-05-30 at 20:38:

On Linux (and Mac-OS X) the function dlopen() can be used to load a library

at runtime, and once open, dlsym() can be used to obtain a pointer to a

given function. Windows will have similar functions but I do not know the

names. The problem you will have, in general, is how to call an arbitrary

function given just a pointer. Some terms you will need to learn are FFI

(foreign function interface), ABI (application binary interface), JIT (just

in time) and assembly code (for x86-32 bit, x86-64 bit and ARM (several

variations)).

An easier way would be to define C functions to be called from Forth take a

predefined argument list and return a known data type. Something like:

int myCfunction(forth *ctx)

where the function will be passed some contextual data were C can pull and

push data to the Forth environment. An example:

int my_sha_hash(forth *ctx)
{
  size_t         len = forth_pop_integer(ctx);
  char          *p   = forth_pop_pointer(ctx);
  unsigned char  hash[HASH_SIZE];

  /* ... code to calculate hash ... */

  forth_push_pointer(ctx,hash);
  forth_push_integer(ctx,sizeof(hash));
  return 0; /* everything is okay */
}

This way, a C function will always be called the same way, thus simplying

things greatly and you can avoid the hassle of learning the ABI and assembly

of multiple different platforms.