Model

[BRIAN SPILSBURY]

LispOs: a Model

Base primitive is a 'byte-chunk'.

Byte-Chunk
 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 'end'.
 set-byte (index value) - gets a byte. relative to 'begin', limited by 'end'.
 get-begin ()           - returns begin.
 set-begin (value)      - sets the start.
 set-end (index)        - sets the end.
 merge-next ()          - arranges for this chunk to merge with the following.
 merge-prev ()          - arranges for this chunk to merge with the previous.

At this point we have a memory system.
Initially all of memory is covered by a single 'byte-chunk' with begin at 0
end at 4 gig or whatever. This does not imply that the memory inside exists.

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 changing
the begin or end positions so that the new byte-chunk is now outside the
old.

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

Note that using this system, we can at a later stage transparently adopt a
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 feel
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.

With the POS there is some amazing silliness.

a) Transparent POS _does not imply_ that your GC process will be affected.
   Transparent POS into an Object Store System Thingy might, and that would
   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 things
   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 layer
   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.

--

Feel free to flame, anything will be better than the 'what name will we call
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 them
fight it out.

Brian Spilsbury