Sun, 11 May 1997 01:47:29 -0500
| From: BRIAN SPILSBURY <email@example.com>
| LispOs: a Model
| Base primitive is a 'byte-chunk'.
Works for me - I cannot really think of a simpler model. You might
want to also have 'aligned-byte-chunk' for accessing data that
is not actually structured as bytes and that needs to be accessed
| begin - value at which the memory this chunk is responsible for starts.
| end - end of this chunk's memory.
| get-byte (index) - sets a byte. relative to 'begin', limited by
| set-byte (index value) - gets a byte. relative to 'begin', limited by
| get-begin () - returns begin.
| set-begin (value) - sets the start.
| set-end (index) - sets the end.
set-chunk(value index) - sets start and end in one call
get-position() - gets present index into byte-chunk
| merge-next () - arranges for this chunk to merge with the
| merge-prev () - arranges for this chunk to merge with the
| At this point we have a memory system.
| Initially all of memory is covered by a single 'byte-chunk' with begin at
| end at 4 gig or whatever. This does not imply that the memory inside
| We can allocate objects in by writing inside a byte-chunk. We can split
| byte chunks by allocating a byte-chunk inside a byte-chunk, and then
| the begin or end positions so that the new byte-chunk is now outside the
| Now we can implement other objects over this byte-layer interface.
| We can have 'free-memory' byte-chunks which are created when an object is
| gc'd, and when two free-memory chunks touch we can merge them together.
| references to 'byte-chunks' should only be obtainable via a secure vendor
| as they will allow naughty things to happen, on the other hand we want
| access to the byte-layer to implement device drivers, etc.
| To implement the byte-chunk system you'll need to implement a
| callable-primitive, this doesn't need scope, etc, you can call it
| via reference. If a typing convention is adopted then at this point
| we can also add type definitions, and we're well down the road to
| Note that using this system, we can at a later stage transparently adopt
| transparent POS system, such as disk-as-memory, ram-as-cache, or we can
| do this initially.
| -- now for a couple of whinges --
| What is this scheme/CL debate? Neither langauge is appropriate as a core
| to an os. Write a micro-lisp with reflection and mop, and then if you
| the need implement CL/CLOS/Scheme over the top, also add in security
| (preferable though something lispish like _capabilities_, rather than
| unix flavour silliness), and threads are a must.
I don't disagree - just not happy about the amount of work needed.
| With the POS there is some amazing silliness.
| a) Transparent POS _does not imply_ that your GC process will be
| Transparent POS into an Object Store System Thingy might, and that
| I agree be silly.
| For persistent objects all that it requires is that the system can
| survive reboot without a loss of non-execution state. This can easily
| be achieved by making the byte-layer of the memory system persistent,
| and imho this is the logical, obvious solution.
| b) If you do make the byte-layer persistent, this doesn't change a thing
| as far as GC is concerned, if no-one's referencing an object it will
| still go away.
| c) You can implement an Object Store System Thingy under this system
| as a database, although why you would want to except for putting
| in a suitcase to take elsewhere I can't imagine.
| d) To make the most of persistence, you might well want to make threads
| persistent, which would be nice. If you don't have a persistent-byte
| to help here, good-luck. What this would mean is you could shut down
| and restart and your programs won't notice, except that simultaneously
| all their sockets to external machines may have closed, and the clock
| might jump a couple of hours. This would be nice.
I have some concern over what happens if the power should go out
or the system should crash. How do we make this robust?
| Feel free to flame, anything will be better than the 'what name will we
| this os that we haven't even defined in any way more than an os that is
| lispy', or the 'I want Scheme! I want CL! I want GCC!' threads.
| Lets at least get some models up of what's possible/desirable and have
| fight it out.
| Brian Spilsbury