The ENative Project

The purpose of the ENative project is to explore the performance possible for a simple implementation of Kernel-E in C++, or looked at the other way, the simplicity, compactness, and readability possible for a Python-scale-efficient implementation of Kernel-E in C++. The inspiration for this project is the widespread satisfaction with Python's simple C-based implementation. The current ENative sources (download enative.zip) are quite incomplete, but implements much functionality quite simply in 938 lines of code and comments.

What we learn should aid efficient compilation of E to JVM bytecodes. We start with C++ however, because C++ costs are clear, whereas much experimentation would be needed to evaluate the performance of alternative bytecode sequences, and the results may be distressingly ideosyncratic to a particular JVM. Given a Java implementation that provides good linking and fast intercallability of C++ and Java code, ENative may be more than academic.

Other Benefits & Request for Volunteers

Given that we must consider the E compiler as part of our TCB (unless we are prepared to audit the compiler's output), ENative is our best hope for a very small but practical TCB for E. If you wish to use E to gain strong assurance of security, you're not going to succeed with Java in your TCB. Similarly, if you want to use E on platforms to which Java hasn't been ported yet, like EROS, or on platforms way too small for Java, like the Pilot, then ENative may be your best hope.

If you find the ENative project interesting, please contribute to it. If you find it very interesting, please volunteer to become its open-source coordinator. I (Mark Miller, markm-at-erights.org) frankly don't have time for any further work on it, though not even enough is there yet to run any interesting benchmarks. For now, I need to stay focussed on the Java-based E, so I've put these sources and web pages up in the hope of enticing someone else to pick up ENative where I've left off. Should you volunteer, I will of course do what I can to help. Thanks.

Ground Rules

The ground rules for this exercise (at least at this point) are

• No static type analysis of E source code
• Only simple scope analysis
• No use of C++'s "virtual"
• No use of C++'s template feature
• No unnecessary use of C++'s references
• Absorb, rather than reify, E's stack discipline
• No portable virtual machine support for stack debugging
• Portable meta-level access to board-state
• Assume a garbage collector
• Impose all costs that a complete implementation would impose
• Impose costs of upgrade-for-prototyping
• Compile rather than interpret
• Call-site cacheing

A Guide to the Implementation

The source files (download enative.zip) currently only provide a portion of the run-time library, especially the polymorphic call mechanism, but excluding most of the primitive data types or operations.

Fat Pointers are the heart of this implementation.

We have not yet implemented a compiler from Kernel E to C++, but we here sketch how we would expect to do so. In the meantime, you can perform adequately reliable benchmarks for small pieces of E code by hand compiling according to the following sketch, and not using any more judgement than you believe a simple compiler would.

• Compiling Variables. Variable defining patterns, variable access, variable assignment, and slot access.
• Compiling Objects. Object expression, Meta facets, Method and Matcher definition.
• Compiling Other Expressions. All expressions other than variable manipulation of object/plumbing definition.
• Compiling Patterns. All patterns other than the variable definition pattern.

Acknowledgements

Ka-Ping Yee for provoking me into doing this, as well as for helpful suggestions.

The implementation techniques used by ENative, in particular the use of "Fat Pointers", is based directly on an earlier implementation of Joule at Agorics. The Fat Pointers of Joule were in turn partially inspired by the Fat Pointers of the Clarity language developed by Ted Goldstein, Mick Jordan, and many others while at Sun Labs.

Dean Tribble & Joule for having done most of this earlier, in a context that E could learn from. Further thanks to Dean for many helpful suggestions.

Of perpertual inspiration is the brilliant history of Lisps and Smalltalks, especially the contributions and insights of Peter Deutsch and Alan Schiffman.