[LMH]Musing

[James A. Crippen]

Before I go to bed tonight I wanted to babble a little bit about my
thoughts of when this project is a little more mature.

Graphics Interface. We've had this discussion before, and I honestly
think we should use X11. This of course require that you have an X
server available, which makes it annoying for MacOS and Windows
users. But... I think that if we use X11 at first we'll still end up
with a not-too-terribly-painful implementation, and I really don't see
why the glue layer between the Exploder hardware emulation and the
'real' display couldn't be abstract enough to port to other display
systems later, like Quartz or WinAPI. This seems to be how things are
going for the McCLIM people.

Input Devices. This mostly seems to be dependent on the display
system. Each provides its own system of input as well as the output. I
figure though that we'll be converting every single event into some
sort of faux hardware interrupt on the Explorer. I forsee this as
being a significantly ugly area, involving a lot of work on speed
improvement. Making it portable however shouldn't be too hard, since
all the various display systems provide the same basic set of input
primitives.

Network Interface. This may be interesting. It's not terribly
difficult to implement on most of the Unix systems out there, who all
seem to have support for some sort of user-mode ethernet device. But I
have no idea how the hell this could be implemented on a Windows
system. Obviously it's possible, given that VMware is doing it, but
the implementation smells of nontriviality to me.

Raw Disk. Having a low-level disk access seems like a good idea to
me. Recent Linux kernels support IDE taskfile access for poking around
on the disk hardware. Maybe we don't need to go that low, but I think
getting the filesystem out of the way could be fairly beneficial. But
then again, most operations on a LispM seem to be processor and memory
bound, and not really disk I/O bound, so maybe it won't be a problem?

Bare-Metal Booting. While I think this could be an interesting hack I
don't think it's a terribly important thing to do. Honestly I think
that modern OS implementations are going to provide invaluable support
for hardware that is nearly induplicable by small projects such as our
own. The closest I'd see getting to bare-metal would be running a very
very simple Linux system with almost nothing in it except the C
compiler, shell, misc utilities, and X11, the system init going into
the emulator full-screen in an X session with nothing else
running. That could be fun to put on a bootable CD-R to show off to
people.

System Software. Eventually we'll have a system that boots and
runs. Software will work on it. I'd like to see us start to maintain
two forks of the System Software, one for physical Exploders and one
for our noncorporeal Exploiter. The initial code base should be the
last and best available set of sources from someone's working Exploder
machine, maybe or maybe not the set of sources that I already have. We
then suck this stuff into a CVS repository and branch it. The branch
becomes the hardware Explorer sources, and the trunk becomes the
emulated Explorer sources.

At this point I must sprinkle you all with fairy dust.

You see, my idea is that once we get a working system it's a great
idea to keep improving it until we have a near perfect emulator of an
Explorer II. But that's not really the 'state of the art' anymore.

With a working emulator there's no reason why we shouldn't keep
polishing it, but I'd like to see work begin on the design of a *new*
system, based on the emulator but with a lot of the unnecessary
hardware simulation taken out and the architecture simplified a good
deal. Basically another iteration of the CONS->CADR->LAMBDA->E1->E2
cycle. This would be *all sorts* of fun, involving design of a new
architecture, lots of fooling around with new opcodes to support fun
stuff like direct disk access, 3D drawing with OpenGL, etc. And we'd
get to retarget the compiler. Yay!

OTOH there's also plenty to be done with the existing system sources,
even without any architectural changes. The GC is certainly put
together pretty well but the latest advances in GC technology could
certainly be applied here. The network protocols need definite
updating, and there's plenty of work to do improving other parts of
the system. ZWEI alone begs for lots of fun hacking. There's all sorts
of neat optimizations that could be done with the compiler. Etc, etc.

Basically what I'm getting at is that getting the emulator working is
just the first step in a long process of improvement. A working
emulator, as John Morrison put it, "brings the LispM to the
masses". But once the masses are involved we can expect lots of
interest in work on improvement. We'll need to be ready and have
thought about it beforehand, or we'll end up like the Lisp community
just before Common Lisp, a bunch of well-defined groups going in a
bunch of completely different well-defined directions.

That's what I'm dreaming about.

Oh bother, I've gotten drool all over my shirt.

Nighty-night.
'james

Give yourself +5 points if you spot the Principia Discordia reference.

-- 
James A. Crippen <james at unlambda.com> Lambda Unlimited
61.2204N, -149.8964W                     Recursion 'R' Us
Anchorage, Alaska, USA, Earth            Y = \f.(\x.f(xx))(\x.f(xx))