Compiling with (More) Idiomatic C, UNIX (and Kontinuations, of course) /j

Let's say, hypothetically, this computer toucher girl is getting to know Scheme, and trying to build a toy Scheme that runs on her AMD64 Linux machine that she loves so much. After some Internet surfing she comes to the conclusion that there doesn't seem to be many beaten paths. There's compiling to machine code using her own calling conventions, compiling to C with Cheney on the MTA, and compiling to C with trampolining. While proper tail calls are important, she doesn't want the output to become too hacky. No more than one calling conventions, no calling alloca with a possibly negative argument, and no hiding intentions by returning a fake thing that needs more calling! It must be direct! [insert satoru iwata]

One day, a devil in her mind whispered to her, did you consider exec? It's very idiomatic, and many books written on operating system design praise Unix's fork and exec for simplifying syscalls and allowing for manipulating the child process's environment!

And that's what she did. The input program goes through CPS [because running your typical program and see multiple processes would be weird] and closure conversion after the frontend is done with it [since we use a flat closure representation, mutable local variables need to be boxed. this is done in the frontend after canonicalization], and closed functions are compiled to C programs that transfer control to another function through an exec call. Since exec replaces the whole process image, and she's cutting herself some slack for coming up with such a genius compilation scheme, heap data is put on the disk. Each time a new object is allocated, a fresh handle would be generated, and the corresponding new file is written. A simple mark-sweep garbage collector is implemented, deleting files no longer referenced when total storage usage reaches a set threshold. The C generator even indents the output properly!

If you want to see it for yourself, you can grab the code from my diskeem repository. It contains relevant shell scripts for running both systems in the comparison.

How well does it work?

This is the compiled nboyer 0 benchmark running:

$ time ./entry
95024

real    99m26.367s
user    7m55.933s
sys     55m3.851s

This is the same program running on Chez Scheme:

> (display-statistics)
    1 collection
    0.045488857s elapsed cpu time, including 0.000011750s collecting
    13.791942014s elapsed real time, including 0.000013720s collecting
    2205904 bytes allocated, including 3792 bytes reclaimed
> (load "nboyer.scm")
95024
> (display-statistics)
    2 collections
    0.055630442s elapsed cpu time, including 0.000713551s collecting
    24.588486877s elapsed real time, including 0.000722835s collecting
    16217664 bytes allocated, including 7506864 bytes reclaimed

(crickets)

FAQ

Q: Are you stupid?

A: yes :3

Q: Your code is terrible!

A: yes O.O