LLL

[Mike Prince]

On Sun, 18 Dec 1994, Dr. J. Van Sckalkwyk (external) wrote:
> I was thinking of having specific stacks etc as one level up, and the 
> LLL merely being a pretty general method of describing and 
> manipulating available resources. A sort of symbolic assembly 
> language.

There is one stack that I think we have to have; that is the return stack.
Please let me know if another solution exists.  As far as the rest, I 
think the lowest level of memory allocation (blocks of data) must be 
handled by the kernel to prevent unauthorized accesses.  Some have 
suggested a capabilities scheme based on pointers (if you can see it you 
can change it).  I'm for a more restrictive one based on sections of code 
(methods) having a collection of protected data.  If you (an agent) want 
to get at the data, you execute the method owning the data to extract 
it.  It actually boils down to a relatively simple system (all things 
considered) and is easy to migrate.  More about that later...

> > > > >     b. necessary flags
> > None, stack holds info.
> As above. From my minimalist point of view, I think it is an outrage 
> to store information in a byte / word / dword when a bit will do, and 
> is readily available to be used on all systems (are there systems 
> without a carry flag)? This is different from having a wealth of 
> conflicting and complicating standards, where one will do! Maybe I'm 
> just being particularly biased this am!

I would love to use a bit, when that is all that is needed.
Can we get away with making the LLL manually pack bit fields into our 
"integers"?  Please give me arguments (for or against this).  I'm afraid 
I'm part of the group that wants to pack 'em into words.

> > > >     c. Suggested primitives:
> > > >         ADD SUB MUL DIV SHR SHL ROL ROR OR XOR AND NOT NEG
> > > >         TEST_UNDER_MASK
> > > >         REQUEST / FREE "memory" block (in broadest sense)
> > > >         POINTER creation
> > > >         GET / PUT
> > > >         PUSH / POP
> > > >         CONDITIONAL_BRANCH (or skip)
> > > >         "CALL" / RETURN
> > > >         FORK / JOIN
> No! They are just primitive concepts (with mapping to specific 
> instructions on whatever machine you are working!!). I'll give you a 
> rough demo in my next post.

Actually I think we're saying the same thing.  The LLL ADD, can either be 
roughly (quickly) compiled to a WYSIWYG macro-expanded machine code, or a 
slightly optimizing compiler can see we pushed the integer that the add 
instruction uses as one of its arguments, so it becomes
	ADD *DataStack,CONSTANTVALUE
(please excuse the Cish assembly language)

> > Certain operators ADD would have a ADD8, ADD16, ADD32, versions for 
> > multiple types.
> 
> This I do not like! In terms of our "system architecture" I would far 
> rather have one "word" size (32 bits). KISS. Necessary & sufficient.

There are two problems I see with not having multiple types;
	How do you deal with characters?  In my version with an untyped stack
	you can work with characters easily on the data stack.  I worry 
	that a fixed size stack would force everything into 32's and cause
	unnecessary memory waste both for local storage and transmissions.
	
	What if my program only needs 16's, but we've selected 32's for
	the word size.  How much of a performance hit will that exact
	on a 32bit machine, 16bit machine, 8bit machine (read embedded).

I do recognize that it would simplify a lot of things and the model would 
indeed work fast on many (probably most) modern computers.  I just want 
my cake too =).

> > > >         HOW_LONG
> Primitive to let you know (an estimate, perhaps) how long a 
> particular primitive will take to execute. For example, I see 
> "Request" (memory) as being able to provide a linear chunk of any one 
> of a variety of different types of store .. How_long would let you 
> assess whether it is feasible to use the chunk you obtained, for a 
> particular application!

I don't think we should have this.  Instead let's have someone provide a 
system clock (kernel or in user space).  A program could come with 
(optional) a benchmark suite targeted at resources the program would 
use.  Your HOW_LONG is derived from checking the system clock and running 
the benchmark.  If you want the really simple version, have it clock
one instruction.

There could also be a standard method which returns system dependent 
instruction timings.

What I'm saying is HOW_LONG is above the kernel and LLL.  Whatdayathink?

P.S. don't take my benchmark suite as a big thing, just 40 or 50 bytes 
of code.

> But it goes even deeper than this! 
> 
> For ultimately, we want our OS to interact with the real world, with 
> humans, and with other OSes. So I think that it is a very bad idea to 
> ignore other OSes that have been successfully doing this for 
> (sometimes) billions of years - living organisms. Especially as our 
> "OS" will be continually interacting with them!
> 
> Therefore, before we say that certain items are "primitives" (MUL, 
> DIV) and others are not (SEE_VERTICAL_BAR ?), let us be sure of our 
> basic needs, and how we intend to fulfil them!!

Please explain more.  I get your idea, but I don't see another solution 
(but again, I'd be delighted to hear of one).

I am very interested in using biological systems as models for our own.  
I'm even going so far as to rename several of my kernels structures to
reflect this orientation.

Mike