The problem with doing original design is ofcourse that it typically takes quite a bit of time to get it very far.
I am currently in process of writing a native x86 compiler for a Lisp dialect similar to Scheme, which I intend to first bootstrap normally, then make it compile JIT, then transform it such that it can "bootstrap on the fly" effectually replacing more or less all of the system including any runtime on the fly (that is, without restart, relying on garbage collector to get rid of old code as well as data), at which point I intend to move it to work on top of bare machine.
My current iteration of compiler (written in Scheme) is able to compile only trivial programs, but the resulting code is able to handle much of the intended semantics with a really minimal runtime. It doesn't assemble on-the-fly yet, requiring GNU toolchain for assembly and linking, but the way the system is designed, it will be much easier to fix those once it's been bootstrapped.
It is also able to avoid heap allocation as long as no "large" (non-immediate) objects are created, closure creation and receiving variable arguments in "rest" lists being currently the only things that implicitly allocate memory. Notably, none of the following requires heap to even be present:
- variable arguments into optional parameters
- multiple return values
- fully general tail-recursion
In reality the current system can't be started without a heap of some sort, but it is possible to write non-trivial code that can survive without allocations after startup. This in turn is useful property to have to be able to implement low-level stuff like the garbage collector with the language itself.
Next thing to add to the compiler will be separate compilation of libraries, such that I can start implementing rest of the runtime system with the language itself... including said garbage collector...
But why?
During my last iteration of OS development, I came to several conclusions:
- the proper way to do what I want, is to use event-driven programming with asynchronous messaging
- programming on top of truly event-driven system with something like C is next to impossible for normal human beings
- if I'm going to need a more suitable language anyway, why constrain the system by using a kernel written in something like C?
- if the only unsafe features of said high-level language are a set of unsafe primitives, and if said high-level language is always compiled from either source-code or some sort of intermediate bytecode, then it's almost trivial to establish system security (as long as we assume or prove the final-phase compiler correct) without hardware mechanisms
- there is no reason why said hardware mechanisms couldn't be used to run untrusted native code in a safe way, while rest of the system enjoys the benefits of language based security (!!!)
While some of this stuff might not be "original" in the sense that much of it has been done in one form or another on some system or another, it is original enough that anyone shouldn't expect anything really working anytime soon.
But at least I'm progressing...