LLL

[Dr. J. Van Sckalkwyk (external)]

Dear Mike (et al)


> > On Sat, 17 Dec 1994, Dr. J. Van Sckalkwyk (external) wrote:
                                      ^^ Yep. They screwed up the 
spelling of my surname. Not the first to do so. (van Schalkwyk)


> > > 2. DEFINE OUR LLL
> > >     a. symbolic registers, including "pointer registers"
> 
> Forth like, so we have
>     DataStack   (a typeless stack for data manipulation)
>     PathStack   (how to return from subroutine calls)
>     Code        (points to current METHOD)


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.


> > > >     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!



> 
> > >     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
> 
> Yes to all the above.  They are all one byte codes that work on data on 
> the stack (except for push).  

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.

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

> 
> > >         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!



> > >         (relevant graphic_display primitives)
> > >         (relevant visual_perceptive primitives)
> > >         (relevant speech primitives)
> > >         (relevant sound_generation primitives)
> > >         (relevant hearing_perceptive primitives)
> > >         (? relevant spatial_descriptive&perceptual primitives)
> > >         GET_FROM_STREAM / WRITE_TO_STREAM
> > >         ? DO_CRC
> > >         ? COMPRESS / DECOMPRESS ??!!
> > >         ? RANDOM number generation
> > >         ? SEARCH / SORT
> 
> These are all libraries/METHODS.  Not part of LLL primitives.

My belief is, not necessarily. We do NOT have to stick to traditional 
concepts of libraries etc. Our primitives should be _necessary_ ones. 
Intimately bound up with this is the necessity to do things in real 
time. Another biological example, I'm afraid: Consider your eye -

The retina does an enormous amount of pre-processing before it passes 
the information on to the visual cortex. Why? Surely, because it 
works! It might be feasible to do it some other way (although in this 
particular case, I doubt that things would work as well)! But here, 
the retina provides complex "primitives" to the cortex, in preference 
to a load of raw data that the cortex would have to process! Do you 
see the analogy?

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!!

One of the major reasons why some OSes are such unmitigated fuckups 
(eg DOS) is because developers have not said "what are my ideals" but 
rather just "what do I have at hand" or even (640k boundary) "what is 
expedient for today"! I do NOT mean that we should design a pure 
ideal system that will not possibly work, but I do believe that 
software should lead the hardware rather than (as has been happening 
since the dawn of computers) hardware leading the software by 10 
years! The real cost of developing any system now resides in the 
software, not the hardware. So why does the tail wag the dog?

> 
> > >         ? INSERT into block
> > >         ? EXCISE from block
> 
> These two have a LLL bytecode version.  There will probably be HLL 
> versions as well though.



Agreed about the HLL versions (having LL primitives does not of 
course preclude similar HLL constructs). For comment on word 
"bytecode" see the above.



Bye, JVS.