The LispOS Project: a position paper, part 2

[Peter.VanEynde]

On Tue, 3 Jun 1997, Dwight Hughes wrote:
...
> I am probably showing my ignorance here, but here goes. I see the 
> "microkernel" as more hackable/modifiable/extensible, relative to the
> rest of the OS, than the "monolithic" kernel. It would appear to
> be easier to add new primitive operations with better control and
> understanding of their interactions with previous primitives (needed
> to support the rest of the system) due to the factoring of the
> code into the absolute essential mechanisms of the microkernel.

There are "interfaces" "in" the kernel between the major parts, like a VFS
(virtual filing system) and (not sure about this one, only heard plans) a
virtual memory management system. I see Linux like a microkernel where the
different "severs" are compiled in (or are modules) and where you do
function-calls instead of sending messages...

> | b the metal is a minimal kernel, I think Linux will fit the bill. Like I
> | said before: just think that Linux is an abstraction layer.
> 
> I would, at least from time to time, like to get down to the metal with
> some
> lower-level Lisp (or a Lisp designed with that ability in mind).

As long if you don't want to intercept IRQ's you can with CMUCL... Just
mmap /dev/mem (?)...

> | I would like option a, but nobody would buy it :-(.
> 
> I wonder what could be done these days with a handful of Altera or Xilinx
> FPGAs - I've never really known enough about the LispM designs to be able
> to make an estimate. Might be worth a bit of thought -- perhaps a
> "freeIvory"
> (well, "cheapIvory", hardware is never free) design on PCI bus cards?

The problem isn't only the ISA architecture. PCI isn't _that_ nice... Just
see the NE2000 PCI clone problems at the moment with Linux... And my
matrox PCI card has several 100's of registers that all interact. :-(

Combine that with a reluctance to give out documentation and we get a nice
mess. :-(

The Lisp compiler can hide the complex CPU, let the Linux/Hurd/Win NT
kernel hide the complexities of the hardware :-).

> | I was thinking of this. It _can_ be done with a minimal kernel module and
> | mmap. But I've got philosophical problems: if you want to collect the
> | garbage in memory, you need to know what memory is referenced by the
> | swapped out memory. And how can you know that without swapping it in, or
> | keeping an expensive "pointers from outer space" list? But I know only a
> | little about GC, so can someone enlighten me?
> 
> One of the LispM guys here (sorry, I can't remember who exactly right now)
> first explained a bit about this -- the details I'm still trying to figure
> out, but the payoff is very high efficiency usage of resources (and thus
> considerably better performance). One point was that the GC would progress
> as far as it could to all objects that it could reach *within* memory
> before
> starting to swap - swapping only if absolutely necessary in effect; what
> it can resolve it does - if not, postpone. You could, for example, have
> the GC follow pointers within memory until reaching one that faults, then
> add the pointer to a "to do" list to tend to later. There would be
> limitations
> of course - programs/processes that spew a lot of small short to medium
> life
> objects would seem to benefit the most from this approach. You would
> probably
> not want to run this way *all* the time (or at least be able to adjust the
> GC's swapping-phobia level).

Oh. That would mean that you would need to know _all_ references to the
pages in memory made by the pages in swap. This would mean that you would
need a table of referenced locations for every page. And if you swap in a 
page, you would have to modify all the tables of all the pages referenced
by this page. Right? It all seems a lot of work... Why won't a
generational GC have the same effect? You would only have to know the
inter-generational references and Generation 1 (the youngest) would remain
largely in memory if you use LRU.
 
> | There is a "RT-Linux" project that runs above the normal kernel. It would
> 
> | be trivial to add extensions, or to add a call-interface...
> 
> Doesn't RT-Linux drastically limit or disable "normal" Linux capabilities
> like networking and such? I think the limitations are due to the hard-
> realtime constraints it is operating with though, not the essential 
> idea.

I'm no expert, but I remember some modifications to the serial port
driver. There is an article in a recent Linux Journal that explains it all
:-).

> | I would just like people to help the free-clim project and add ports...
> | I've been _running_ the first release, so it sort-of-works. It just needs
> | programmers. Even bad ones can help... just look at me :-).
> 
> I've been studying it when I get a few moments, still have a ways to
> go though.

Same here...

> | > Your point that our time would be better spent *not* recreating
> | > the Un*x software library is well taken.
> | As I said before, we don't need a revolution, we need slow infiltration.
> | If LispOS is easier to program in, runs on all conventional OS, and can
> | communicate with the other programs, then people will flock to it...
> 
> A slow infiltration may be all we can manage anyway, even if we're both
> good
> *and* lucky. This is one whale of a project, seen as a whole.

Ba. We can do it a piece at a time. As long as people communicate they can
work at different levels (CLIM, GC, threads, Lisp-chip) and use each others
work.

At the moment I'm trying (at a slow pace) to "kidnap" the available lisp
sources, clean them up and offer them as a "plug-in" for CMUCL. That and
manuals should (I hope) convert a few people to use Lisp a bit more...

Groetjes, Peter

--
It's logic Jim, but not as we know it.
Look in keyservers for PGP key.
Version: 3.12
GS/CS/L/C d->? s+:++>+@ a-- C++(+++)>$ ULOS++>++++$ P+>++++ L+++>++++
E>++ W+(--) U++>+++ o>+ K? w--- O>+@ M-? V? PS++ PE(--) Y+ PGP+>++
t++>+++ 5++ X++>+++ R tv b+++>++++ DI++ D++@ G+>++ e++>++++ h!>+ r+ y+