Reviving TUNES

[iepos@tunes.org]

>    I've been working on my own little Forth-OS project for a while, not
> really paying attention to Tunes.  I guess I didn't miss much... it barely
> looks alive.  I'm getting into it again... I'd really like to see some of
> these ideas put into practice, breath some life into it...

Yes... ideas put into practice... breath some life into it...
Hopefully TUNES will become alive soon...

>    Our holy grail is the Garbage Collected Distributed Persistent Object
> Store... and we also want language translation, migration, abstract
> interfaces, an optimizing compiler, automatic proof of correctness... 
> Let's set all that aside for now and reach for something within our
> grasp: "TUNES--", because that's better than nothing, better than unix
> or windows.

Good idea... maybe one goal to reach for is a good Storage system, 
i.e., a storage system in which there is not garbage or otherwise
wasted memory all over the place, and in which not much time
is wasted managing memory either, and most of all, in which
low-level bugs do not occur from accidental mismanagement of
memory by the programmer.

So far as I know, there is no existing system that has a nice
storage system from the ground up.

But, there are lots of promising techniques that one might use
for storage management; for instance, one might employ a
"mark+sweep" or "stop+copy" algorithm (or some better algorithm,
I'm not really too knowledgable on garbage collection) as a
general way of collecting garbage...

But, there is one particular technique that I've been quite
interested in recently; here it is: 

  In general, refrain from passing around pointers; instead,
  pass around, on the stack, the necessary data structures
  themselves...

This is really pretty obvious, and is certainly not a new idea,
but it seems terribly under-used. In C, it is not portable to
declare a local array of runtime-determined size, and even if
it was, there is no way to pass it to another function (unless
it is wrapped in a structure I suppose, but even then, I wouldn't
dare pass it to another function, for fear that the compiler
would implement the pass using a slow memcpy, even if it
was already in the right space on the stack). 

Anyway, it seems like an interesting idea to me... if a system
is going to support concurrency (and one would hope it will),
then one would probably need to have a stack for each thread...
They would need to be dynamically resizable and would need to
be able to move around to make room for each other (on x86,
a good way to do this I guess would be to trap the segfault when
the stack goes beneath its bounds).

>    I wouldn't worry about translating C programs automatically... it's
> probably easier to do it by hand, or better yet, start from scratch. 
> Bad languages make for bad programs which could really use a redesign.

Yes, C has its flaws... I wouldn't try to translate C programs
automatically, either.

>    The "official" plan is to use Forth as the LLL (we'll need a few I/O
> drivers too) and Scheme as the HLL- (we'll want a simple memory manager
> for that).  We can use Retro-Forth as the LLL and model our Scheme after
> TinyScheme.  Retro also has an assembler.  We can do a lot with Forth and
> Scheme; it could be a useful OS, as-is.  TUNES--.

Interesting idea... Retro is quite interesting. But, I'm curious...
Why are you interested in Scheme? Why not do the whole thing
with a FORTH-like language?

>    Then we'd get started on this Persistent Object Store (simple at first) 
> and an automatic proofing program.  After that, eventually, I guess we'd
> meet up with the real HLL - Slate or something like that.  Whoever does
> the HLL will have plenty of time... it would be pointless to set a date
> for any of this stuff because you KNOW we'll be late. :)  Just take it as
> it comes.. 

Sounds like a plan...

>    I don't intend to do all this; I intend to add networking and graphics
> to Retro instead.  I just thought I might inspire someone else to take the
> next step. 

You might be interested to know... I am also working on a "TUNES--"
project, which I call CLIP ("Combinatory Logic Interactive Playground").
But, don't expect it to get anywhere real soon. Billy has just 
convinced me that I need to start over and do it an entirely
different way :-)

Here is the plan:

  1) implement a cheap version of CLIP in C
  2) use this system to construct an x86 kernel for a reasonably
     efficient CLIP system.

The system will be very strongly based on Stacks, drawing ideas 
especially from the FORTH-like system Joy... Each thread has
two stacks: a data stack and an instruction stack. The system
will operate by popping instructions off the instruction stack
and executing them; most instructions would operate on the data
stack, although some might perform I/O, and a few might operate
on the instruction stack (for instance, there will be an instruction
which pops a list of instructions off the data stack and pushes
the instructions onto the instruction stack; this would be the
core "control" instruction, and is somewhat like a subroutine call;
it is known as "i" in Joy).

Anyway, I suspect that a speedy processor could be constructed
with this architecture in mind, but x86 is not one, anyhow...
The most natural way to implement the system is with big-time
self-modifying code, which I think does not spell efficiency
for x86 processors with their strange cache and branch-prediction
units... I'm not sure how this might be handled...

Again, I haven't even really started implementing this, so don't
hold your breath...

> Tom Novelli
> 
> PS - I'll round up my notes on persistent storage, etc., and upload them.

All right... Good luck on Retro...

- "iepos" (Brent Kerby)