a virtual machine
Sat, 26 Apr 1997 00:13:34 -0700
> Not much lip service is being given to the idea of a virtual machine.
The value in a virtual machine is a promise of portability,
and I don't think that is very important right now.
Lisp is also itself a virtual machine -- the instructions look
like (operation arg1 arg2 .. argn), with a few special operations,
like "unwind-protect", et al.
My opinion is this LispOS need only run on cheap x86 machines in the
beginning. In many cases the hardware is better than cheap, it is free --
people have them lying around already.
This means x86 native compilation is perfectly adequate for now,
and is well-known technology that everyone has already implemented.
My model is a web server-side system, it doesn't matter
what software someone is running on their desktop, it'll have a web-browser,
and that will be all they need to use this LispOS system/software.
I lean towards Linux, because it is already widely used on PC
hardware, and supports tons of devices, disks, tape drives,
CD-ROMS, etc, and can be hacked as needed without much trouble.
I've got experience hacking Linux, I've studied the code a lot
(at least the pre 1.0 kernels), when I wrote my own mini-OS
that was used in my x86-based X-terminals. So I also understand the
hardware in detail. But I don't think we should reinvent (and re-debug)
this low-level stuff, unless it yeilds a lot of value, and I can't
see much extra value in a disk device driver which is written in Lisp.
I should also say that the system I have in mind could be
able to run on a network of x86 machines as a "parallel" machine
to increase performance as needed -- plunk another cheap box onto
the local network, and you've got some more computing power to use.
This comes from the use of a persistent object system,
which I keep coming back to.
The idea is similiar to how ObjectStore works for C++.
Use the page-level VM hardware protection to fault-in objects
from the persistent store, have transactions for synchronization between processes,
and have support for read-only/shared-write/copy-on-write semantics.
This can work on top of Unix -- that is how ObjectStore does it,
and how TEXAS Persistent Store does it, ...and that is how I've done it.
It allows the Lisp heap to be persistent and shared by multiple
processes. It might be more efficient running "directly" on the
hardware, but the performance difference is not significant,
the disk and network speeds are the bottlenecks.