Greetings and Comments

[Justin Sampson]

Greetings to anyone listening! There doesn't seem to be much activity
here, but I would like to get involved with the Tunes project. It seems
very much in tune (pardon the pun) with my own musings on OS design. I
am able to work on the project for a few hours per day.

I would like to quickly summarize what I have gleaned from the web pages
and mailing-list archive, tempered with my own feelings on some topics.
Hopefully I may clarify things for others as well as for myself.

Perhaps the most fundamental step in the design of a computing system is
the definition of the underlying virtual machine to be implemented. In
Tunes, this forms the semantic basis of the "high-level language" (HLL).
The HLL shall effectively serve as the assembly language of the Tunes
virtual machine (similarly, C may be called the HLL of POSIX). The "low-
level language" (LLL) is implementation dependent; the Tunes run-time
system for a given implementation serves to translate or interpret
portable HLL code into local LLL instructions.

Tunes hopes to be a provably-secure, distributed, object-based computing
system. To these ends, the HLL virtual machine must enforce formal
specifications of all code and data; this further requires that the HLL
be a higher-order, reflective language. To allow sane development, the
HLL must be self-extensible, with a fine-grained and persistent object
model, and should support various programming styles (imperative,
functional, etc.). Some sort of access to the LLL will be provided from
the HLL for hardware device control.

As it stands now (and as I think it should), the HLL development is
tending toward a specialized dialect of LISP. The LISP syntax is
automatically reflective and self-extensible, and it supports multiple
programming styles. Adding formal object specification for provability
is almost trivial.

Tunes implementations may take any form, as long as they functionally
perform as interpreters for the HLL. Thus, a straight interpreter may
be written using C as the LLL running on POSIX; for greatest efficiency,
an on-the-fly translator could be built as a loader for a stand-alone,
non-kernel, cooperative-multitasking system; a pathological example,
but still Tunes-compliant, would be an HLL interpreter running as a
monolithic kernel with preemptive multitasking.

To support distribution, standards will be developed for communication
and migration, which must (like all interactions in Tunes) be provably
secure using formal specifications. In heterogeneous environments, in
which multiple Tunes implementations running with various LLLs and data
formats wish to interact, the run-time systems must be able to decompile
objects and process states into some portable data format.

A highly modularized, component-oriented development style will be
encouraged, to allow customized applications and to promote competition.
Some standard interfaces will be offered, but the focus will be on
extensibility.

The foremost item of business in the design of the Tunes system is the
definition of the HLL (on which I would like to work). It seems that,
due to lack of interest among other project "members," Francois-Rene
Rideau and Patrick Premont have gone ahead with tossing around some LLL
code for the i386 implementation, though they still don't have a very
good idea of what they're trying to implement.

How does that all sound? Is anyone else out there?

Looking forward to a useful system,
- Justin Sampson - hoperift@armory.com -