Some comments on LispOS/LispVM/SmalltalkVM/misc

[Fare Rideau]

> Fare Rideau has a number of interesting questions
> and ideas concerning a LispVM
> -- some of which served to reroute some of my thinking.
> (By the way, the TUNES project is fascinating -- putting these
> concepts under the LispOS would be awesome,
> assuming it all reaches expectations.)
>
Thanks for the compliment ;-)

> However, I believe the low level of the Smalltalk VM
> as it was first presented as a defacto standard
> has been the source of many of the practical problems
> that have followed the language system to this day.
> [prediction of similar problems with Java/JVM]
>
The worst VM in the computer industry has been the i8086
that has been crippling software progress for years.
Building an OS on a low-level basis is crap in general,
even if the LVM is better than the i8086 instruction set.
Do people ever learn?

> If we want to design a VM to be implemented in hardware,
> then the low-level of the JavaVM and SmalltalkVM
> are exactly what one would want
False! The real elementary hardware we have
is transistors (atoms?), not CPUs;
moving the implementation to hardware doesn't reduce
the overall complexity|cost at all!
The RISC and MISC paradigms have proven the opposite!
Unhappily, RISCs are following the same trend of hardwarebloat as CISC,
and nobody funds MISC.

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.
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.

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.
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.

> If we want to run fast on standard hardware,
> we have to design a high-level VM. [APL example]
Exactly.

> Any VM we might create should use high-level constructs
> - ASTs  are a good start.
That's what I suggested in my previous message:
the LISP sexps *are* an AST, and an efficient binary sexp representation
is all we need for a portable binary code system.

> [Oberon example] <http://www.ics.uci.edu/~juice/intro.html>
Good.

> They claim the compact representation of the VM code actually allows them
> to load the VM code, translate to native, and begin execution faster than
> they would be able to just load the same generated native code
> from the hard drive.
Sure, why shouldn't they?

> 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.
Then Microsoft can sell Visual Dynamic OS if they want, I don't give a damn.
Commercial software has been the enemy of software development for years,
let's put an end to it!
Down with commercial software, Long live commercial software services!

> -- using the Utah Flux OS toolkit to do the grungy bits -
> probably with an assortment of Linux drivers added to the mix.
A C->HLL program tuned to the Linux driver semantics would be great!
Yet another dream of mine - see my page:
http://www.eleves.ens.fr:8080/home/rideau/Tunes/HLL/metatranslator/metatranslator.html

> As the design develops and insight is gained we can then
> define something of the sort used in Juice
> (Oberon is not a dynamic language after all),
What's a dynamic language? Lisp is just a language with a unique static type.

> and we can pay attention to support of other languages then also.
Yes. Why restrict to Lisp, or worse, to a particular flavor of Lisp?
Let's just provide a high-level abstract model,
with bindings possible in any real language.
This does raise problems as for communication between
with richer type systems than LISP...
But the problems are already present in LISP,
if we want an OS that allows secure/safe inter-module operation...

> As for running Java bytecodes on and with the LispVM
> - YUCK!, and yet again YUCK! --
> however, getting a separate JavaVM to run
> within the *true* LispOS environment shouldn't be any big deal.
Sure! Why should it? I don't understand why we should need to
build an OS on JVM to run JVM code. Are UNIX/Windows/MacOS built on it???
Yet they can all run JVM code!!!

> If you want to compile Java in the LispOS environment however
> -- I would have nothing against compiling Java
> to the eventual LispVM/DynamicVM or extending it a bit to help with that
> - but we don't need no stinking Java bytecodes
> <g> in "our" LispVM. This could be a real plus actually -- 
> if Java compiled to the LispVM roars compared
> to Java compiled to the standard Java bytecodes and JavaVM,
> that would be just dandy! And it would be
> a real and general incentive to move the LispVM out into the real world.
>
Yup.

> 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...

> I must include Common Lisp in the been there, done that status
> -- but we have to start somewhere.

> 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.

PS: your original post had 120-char long lines, which is Wrong(tm)!

== Fare' -- rideau@ens.fr -- Franc,ois-Rene' Rideau -- DDa(.ng-Vu~ Ba^n ==
Join the TUNES project for a computing system based on computing freedom !
                TUNES is a Useful, Not Expedient System
URL: "http://www.eleves.ens.fr:8080/home/rideau/Tunes/"