Define and implement a low-level language that will fulfill all the requirement to be used as a basis for the Tunes system, including self-extending into the full Tunes HLL, etc.
The LLL is not a back-end to the HLL, but a low-level core for its implementation.
First, the LLL is meant as a somehow portable way of implementing Tunes. It is a purely internal language, that shouldn't make it to most users, may disappear or change drastically at any new major release, and intended to make implementation on many platforms as easy as possible. The LLL project is in some way the basis of any implementation of Tunes.
The LLL is another artificial layer of computerware, that brings an amount of computing overhead. The hope is to minimize not runtime overhead (though we hope not to make it too large), or even compile-time overhead, but development-time overhead.
Once Tunes runs, it is still time to focus on compile-time and run-time speed. Moreover, "the LLL" is not to be understood as an identical abstract language on all machines (even C has different sizes and pointers according to the hardware), but as a general implementation model, that differs according to the hardware.
It is up to the HLL above to make abstract whatever is needed. Every particular implementation may have its own version of the LLL, incompatible with that of other implementations, yet still resembling enough so that all can be called "the LLL".
Virtual machines are an easy way to achieve interoperability, but they have serious performance drawbacks: interpretation of virtual machine code is a very slow process, that loses at least one order of magnitude in execution speed. Of course, if the VM code is properly designed, code can be compiled instead of interpreted; but then, the higher-level the code, the longer it takes to compile to efficient code; and interoperability is such that the VM code cannot be adapted as an efficient low-level code for all possible targets, so a lot of compromises must be done.
So, virtual machine techniques are very useful whenever speed of execution is not a major issue relatively to compactness of code (with associated speed up and cost reduction in data transfer/storage). This is particularly the case when performance-critical primitives can be isolated in a few locally-optimized code, but isn't enough for high-performance inter-operable software.
And very importantly, we refuse the idea of having a single priviledged virtual machine: that this machine would be built statically as a standard for all future work, without knowledge and tuning of this machine, or even with tuning of the machine for today's hardware and software, whereas future hardware and software performance constraints are most likely to change. Such a VM would be no better than the hardware-based standard that IBM-PC under MSDOS constituted up to now; perhaps with a simpler virtual hardware, but still a hardware-based approach.
Surely, the Tunes project should allow and encourage VM techniques to be used whenever useful; some implementations might share a same VM, and the LLL might be a good basis for such a VM. But Tunes just won't embark on a universal VM as a central static concept. Also, a VM won't solve any problem but interoperability of software above it with hardware below it.
It couldn't be C or assembly, because it has to actively support the low-level memory model used to implement migration and annotation (which for a standalone system would be persistency, GC, and weak pointers).
We do support assembly, as part of the LLL, and are aware that full control over the hardware is the only way to achieve near-optimal code.
However, we are confident that eventually, most programming should be done at a higher level, and that even low-level control could and should be done with high-level tools that warranty that the low-level interactions have the right semantics while optimizing code.
As for the cases where better code than available optimizer produces is wanted, we feel that adding specialized optimizer tactics leads to safer, surer, more reusable and portable results, that can be checked, whereas hand-writing optimizing leads to unsafe, short-lived code.
The HLL/LLL concept is all about an harmony between complementary constraints of programming: