Some comments on LispOS/LispVM/SmalltalkVM/misc

[Alaric B. Williams]

On 28 Apr 97 at 13:07, lispos@math.gatech.edu wrote:

> The worst VM in the computer industry has been the i8086
> that has been crippling software progress for years.
> Do people ever learn?

Nope! It's a meme thing. [casually shifts the blame to a buzzword]
 
> If you want *fast* hardware,
> you must move all the elaborate features to software,
> where optimization can be done once at compile-time,
> instead of being repeated over and over at runtime.

Yes. Hardware "optimisations" - pipelining, branch prediction, etc.
are all "softwareish" operations being done in hardware! And they
get repeated each time around the loop... isn't that why people
moved from interpreters to compilers in the first place...

> Hardware should be minimal to be fast: a minimal core,
> and just the few helper functions required to speed the common operations.
> Instead of designing an abstract model and require that the hardware
> implement it (typical braindeadness of Von Neuman worshippers),
> we should see what can be done naturally fast in hardware,
> and adapt our compiler technology to it.

The problem, as always, is memory bandwidth. A MISC-like system,
in fact veritably VLIW, with a meg of SRAM (~5ns access time, anyone...)
which is executable and built into the chip or near it, perhaps; the
SRAM can hold the OS core and things like addition systems, and
basically act like PROGRAMMEABLE microcode. When a lot of code has to
be executed that will not fit in the "code cache", then we put an interpreter
in the "code cache" that interprets the CISCy VM the bulk of the code 
is in, would offer efficiency in memory bandwidth use; a compiler would
preanalyse the code for common operations, compile them to VLIW code,
and put them in the SRAM. I haven't thought about this in much detail, 
not being a hardware guy, but the principle is like dictionary compression;
recognise common patterns and send them ONCE, followed by references back
to that pattern. So we're compressing the rate of data flow from the 
slow-but-cheap dynamic RAMs.

> As for the implications on OS design:
> if we want real hardware independence,
> and being able to take advantage of paradigm shifts in hardware design,
> we mustn't follow the trend of low-level VM hypists.

Agreed. 'coz then we're screwed when we wanna compile for FPGAs.
FPGAs are massively parallel. OCCAM is usually used to program them.
A VM that can take advantage of FPGAs must be massively parallel
too; data flow diagrams would be nice, with a concept of "flow of
control" added for loops and things like that.

> UNIX, Windows, and C-based architectures will never ever be able
> to take advantage of masspars and MISC computers,
> because they rely on a low-level model that just ain't fit.
> LISPOS (or TUNES) will be able to take advantage,
> because it will be a high-level model.

And ARGON! And ARGON! Eventually...

> > However, for now I think that we should concentrate
> > on the creation of the "true" LispOS -- or DynamicOS
> > (probably a better commercial name)

> Fuck commercial names! Let's write real good free software code,
> whatever the name.

Thinking about good names and stuff does /help/. I was born with a
warped sense of style, so everything I do either has a utilitarion
acronym if I was in a hurry, or it has a /theme/... it just adds
that comforting professional edge, and gives a sense of atmosphere.

> > I do not think we need to create *anything*
> > with that been there, done that flavor.
> > There are too many good ideas and concepts that have been crushed/dropped
> > in the rush to Unix or MacOS or Windows due
> > to these OSs built-in hostility
> > to everything that doesn't operate exactly like themselves.
> > We can take the best ideas and models to make a synthesis
> > the likes of which has only been hinted at in the LispM.

> Here I invite everyone to comment on the TUNES project...

Say, take a look at ARGON too, while you're at it; my own pet project.
ETTC (estimated time to completion) 5 years; I will get through university
without working on it, since my Uni will want to claim patents!!!!!!!
NO!!!!

Anyway, the first naff implementation will be written on top of DOS
(laugh, go on!); by then I will have gathered a clique of henchmen to
help with the next stage, which will involve banks and MONEY and
starting a business to develop a "full" version (Utah toolkit, etc;
multiple platforms to start with? I dunno). The software and source
will always be free in the GNU sense, and available for FTP and
being-mailed-to-you-on-a-CD-if-you-pay-for-the-CD; however, to
acheive money to fund further research, we'll sell nice copies of it
in boxes with printed manuals (full sources to same on the free
version, of course), and a GUARANTEE, in that the first reporter of a
bug gets a lump sum for each copy of ARGON they own; big businesses,
therefore, get more money off us if we screw up. Nice incentive not
to screw up, and a cunning advertisement and enticement for the
use of a "bug-retardent" programming language with powerful
abstractions. 

ARGON, BTW, is a /standard/ like POSIX rather than an actual bit
of code. The first ARGON implementation will be called ARGOS, perhaps,
or another noble gas name.

> > Can anyone give a bit of a synopsis
> > of EuLisp -- in particular, how it improves on Common Lisp?

> I'd be interested, too. I don't have enough experience with either
> to provide a faithful synopsis.
> EuLisp seems less ridden with backward-compatibility hacks,
> and I've been told its module system was cleaner than CL's.

Hmmm. Sounds interesting! Me Too(tm)!

ABW
--
Alaric B. Williams (alaric@abwillms.demon.co.uk)

   ---<## OpenDOS FAQ ##>---

Plain HTML: http://www.delorie.com/opendos/faq/
            http://www.deltasoft.com/faq.html

Fancy HTML: http://www.deltasoft.com/faq0000.html