C interop

[xificurC]

C interop

[aoh]

Sounds fun. That is indeed the case. I don't have a computer here at the moment, but adding new system calls involves roughly the following: the prim_sys() function of ovm.c is used to call system calls and other custom C-code. Add a new op there with some test code, make bin/vm, bin/vm fasl/ol.fasl and run (sys-prim 1 2 3) to call the C-code you added and verify it works. Next read the data you passed from owl side to C and verify it works. Small owl strings are actually the header followed by bytes of the string, but you need to make sure the strings are null-terminated before using them. c-string function can be used to do this automatically. After adding e.g. setenv library call to prim_sys, you could test it with something like (sys-prim (c-string "FOO") (c-string "42") null), and when it works, you can add definition of setenv to owl/sys.scm and export it, build owl with make, after which you have setenv at toplevel.

[aoh]

It seems gihub ate my markup. All sys-prim calls above have your added opcode number as the first argument.

[xificurC]

The markup came through in the mail, that's sort of funny. Maybe you redirected some bash script they run :P

So it's just as I thought. Thanks for the quick response. I will try to implement some syscalls in a fork. Hopefully this time I'll stick with this project. Just not sure how deep the rabbit hole will get once I start poking with the C libcalls (haven't really used C before). If I manage to get something working I promise to rewrite your benchmark scripts :)

[aoh]

Just noticed your description in IRC. The system calls are pretty well documented in the manual pages and typically have pretty simple semantics, so they're relatively easy to add to ovm.c. Feel free to ask if you get stuck somewhere or file bugs for the missing calls if some of them seem difficult.

You could use something like a tuple containing information about the data stream contents and some lazy list of data to define the streams between processes, e.g. (port->stream stdin) would give (tuple 'block-stream (port->block-stream stdin)), which you could then be converted to other more structured streams, which can then again be mapped back to block or byte streams and passed to external unix tools.

[xificurC]

Closing this as it isn't really an issue.