1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
|
Approaches to FFI
=================
Calling native code
-------------------
Being called/used/loaded from other languages as a library:
* Can generate header files for C
* Can generate unit files for FreePascal
* ...this approach can work for most native languages.
Calling into other languages:
* Require a SLUL module to be defined, that conforms to
contracts expected by the SLUL language?
- Requires extra work (but it doesn't hurt if there's some
small resistence to adding interfaces to native code).
- But interfaces can be better adapted to SLUL
(and be safe, if the underlying code is safe)
Interpreting foreign code
-------------------------
There are at least 4 approaches here:
1. Load and interpret native code, e.g. x86.
2. Load and interpret WASM or some form other bytecode.
- Would support a lot of languages.
- Efficient to sandbox
- Not memory safe within the program.
3. Parse some "compiler IR" (e.g. LLVM)
- Can be somewhat memory safe (not just sandboxed).
4. Parse and interpret source code (e.g. JS, LISP or C).
- Can be fully memory safe (not just sandboxed).
- Otherwise, it's only feasible for somewhat small/simple
languages, and even then it is probably much harder than
running x86 or WASM.
- Supporting JS would give access to a huge ecosystem.
5. Parse a custom, safe, IR.
- Can be fully memory safe (not just sandboxed).
With option 1-4 there's a possiblity to use an existing compiler/emulator,
but of course, that means loading unsafe native code in itself, so it's not
risk free.
Option 2 (WASM) should be fairly simple to implement in SLUL itself.
For option 4, a JS or C interpreter in SLUL would be really cool. And a C
interpreter in SLUL could provide safety features that C compilers typically
don't provide (e.g. runtime type checks, strict aliasing checks, etc.).
|
