8  Implementation

Scsh is currently implemented on top of Scheme 48, a freely-available Scheme implementation written by Kelsey and Rees [S48]. Scheme 48 uses a byte-code interpreter for portability, good code density, and medium efficiency. It is R4RS-compliant, and includes a module system designed by Rees.

The scsh design is not Scheme 48-specific, although the current implementation is necessarily so. Scsh is intended to be implementable in other Scheme implementations -- although such a port may require some work. (I would be very interested to see scsh ported to some of the Scheme systems designed to serve as embedded command languages -- e.g., elk, esh, or any of the other C-friendly interpreters.)

Scsh scripts currently have a few problems owing to the current Scheme 48 implementation technology.

Byte-coded virtual machines are intended to be a technology that provides memory savings through improved code density. It is ironic that the straightforward implementation of such a byte-code interpreter actually has high memory cost through bad interactions with Unix fork() and the virtual memory system.

The situation is not irretrievable, however. A recent release of Scheme 48 allows the pure portion of a heap image to be statically linked with the text pages of the vm binary. Putting static data -- such as all the code for the runtime -- into the text pages should drastically shorten start-up time, move a large amount of data out of the heap, improve paging, and greatly shrink the dynamic size. This should all lessen the impact of fork() on the virtual memory system.

Arranging for the garbage collector to communicate with the virtual memory system with the near-standard madvise() system call would further improve the system. Also, breaking the system run-time into separate modules (e.g., bignums, list operations, i/o, string operations, scsh operations, compiler, etc.), each of which can be demand-loaded shared-text by the Scheme 48 vm (using mmap()), will allow for a full-featured system with a surprisingly small memory footprint.