Criticism ... synthesis?

[Dr. J. Van Sckalkwyk (external)]

This has three parts.

Part 1. A request.
-----------------

Can somebody _please_ forward me the communications from 14 - 16 
December,
as I was in transit from NZ to RSA and missed all, including 
responses to
my comm of 14 December (am).


Part 2. Response to Fare &c
---------------------------

>Hey, there. Please everyone tell what he thinks about it all, if he
>agrees with me (the no-kernel decentralized, but secure design), or
>Mike's (a monolithic hugeware centralized unsecure kernel, as I see 
it);
>or if you have other suggestions that show that we both are wrong, 
and
>how to correct our ideas so that they be right.

Mike has MY vote. I also think you're being _grossly_ unfair to him.

1. You use "monolithic" in criticism of an idea that is 
straightforward,
and instead postulate a more complex system!

2. "hugeware" ?
My initial statement (and it appears in Mike's compilation of our 
goals)
was that the core code should be +- 20 lines (with everything stemming
from this). Yours is obviously a completely new interpretation of the
word "huge"!

3. "centralised". This is again unfair. Sharing common characteristics
is not the same as being centralised. 

4. "unsecure". I cannot see why security should be better in your 
system
(with what seem to be great big wodges of uncheckable code) than in 
Mike's.



>If we ever upgrade our LLL (or support OSF's ANDF, etc), which we can
>*never be sure* we won't; or you so sure about yourself that you 
think you'll
>manage designing at the first time something that nobody ever will 
be able
>to beat ? I hope not.

In my mind, the _whole LLL idea_ is to have a symbolic low level 
language that
is independent of the machine. A sort of "C" without the fuckups, 
redundancies
and unnecessarily high-level constructs. Sure we can upgrade the LLL, 
but
this should never, ever, mean incompatabilities with prior code.



>   Why ? No one forces you to forget older modules, or to translate 
them.
>Remember we have a distributed system. There might be a "good virus" 
that
>would spread and translate everything to the new standard, etc.

And you call this 
secure???????????????????????????????????????????????????
You are introducing the potential (once we have worldwide "Joy") to 
destroy
the whole of civilisation with a single bad virus masquerading as a 
good
one. Your argument here is the best one yet _AGAINST_ your system.


>> The LLL should be fixed, period.
>   Fixed as much as possible. But our LLL should not be the dogma of 
a new
>computer religion. As long as our LLL is useful, we keep it; when it 
can
>be replaced by something better enough, it will. The only thing is we
>must strive to design it the best we can, so indeed, the better we 
succeed,
>the longer the LLL will survive.

Both wrong, both right. Very infrequently, one may need to EXTEND the 
LLL.
I cannot see any point in ever completely rewriting it - might as well
junk the whole system at that stage, and begin again (which is what 
you
would effectively be doing, anyway).


>> But if you start having many versions of our LLL language we have 
done
>> little to advance a unified coding/distribution standard.
>   I'm not saying everyone should have his own LLL. LLL is standard.
>I'm saying everyone *may* have a different version if it suits more 
his
>needs (and those of enough people so that supporting it is ok). And 
also
>and above all we should consider the *possibility* of upgrading it.

This is NUTS. It's completely CRAZY. The LLL _must_ be standard. That
does not imply that you cannot have "deeper" or "still lower level" 
ways
of implementing the LLL instructions on a particular machine. For 
example,
a primitive instruction in the LLL may be:

        SHL RR,4        ; shift RR register 4 bits left

On a 386, this could be implemented by 4 x (SHL EAX,1)
    or (MOV CL,4 | SHL EAX,CL) or (SHL EAX,4) or whatever. 

You might also have as "primitives" in the LLL items that at present 
are commonly regarded as being on a much higher level eg. compression 
etc.
We must sit down and decide what is desirable in this regard!!



>   I'm for a free world. Freedom allows selection of the fittest. By 
some
>authoritarian way, you may force some good thing to happen, but you 
break
>the dynamics, and won't be able to evolve.

FREEDOM DOESN'T IMPLY TOTAL ANARCHY.



> We want computing freedom.

Agreed. But that doesn't mean that everyone goes his own merry way. To
co-operate (which is really what this is all about) we need a core of
reasonable standards and a common "language"!


I THINK THAT A LOT OF THE PROBLEM IS THAT DIFFERENT PEOPLE ARE 
TALKING ON
DIFFERENT LEVELS. FARE SEEMS TO BE THINKING ON A VERY HIGH LEVEL, AND
CONCENTRATING ON THE HIGH-LEVEL OO SIDE OF THINGS. MIKE & MYSELF ARE
TENDING TOWARDS THE LOWER LEVEL. RATHER THAT ARGUING FOREVER, CAN WE
NOT ACHIEVE SOME SYNTHESIS?


>> Every computer runs machine language (please don't flame me for 
ignoring
>> neural nets and such!).
>   Know about LISP machines ? Or FORTH machines ? Yes they run 
machine
>language. But that does not mean the language is like machine 
languages
>*you* know. Let's define *useful abstractions*.

Agreed. It is vitally important to define a LLL that is sufficient 
for 
our needs, and has a minimum of redundancies. Let's do this.


>> Exactly.  We need to seperate[sic] the low-level goals from the 
high-level
>> goals.
>No ! Like JVS say, the two are closely linked one to the other. It's 
as
>crazy to design the LLL without taking into account its HLL use, as 
to
>design an HLL without taking into account how it may be implemented 
on
>actual machines.

The two complement one another. NEITHER has "priority". They work 
together!



>> Everyone, please refrain from saying anything sucks until you have 
a better 
>> version, otherwise all our time is wasted.

Agreed.



>   [...] Ok.
>   Our binary encoding format has some header that identifies the 
file format,
>its possible version, and the nature of the object inside, together 
with
>some annotation fields, containing, size, CRC, author/originator
>authentification, etc. Then some compressed table of contents, with 
a list
>of imported and exported objects, with their global names, and some
>indicative resource allocation information. Lastly, you have some 
custom
>compressed data that contains the actual code.

Fine. This is higher level stuff. Very high.




>   LLL will some kind of threaded code, with compressed pseudo-
pointers

I've been thinking along these lines. Yep.



>   Now, in-memory representation for the i386 code may be 16-bit or 
32-bit
>threaded code, or byte-code, according to the LLL flavor chosen (and 
needed
>speed). Objects using different calling conventions may easily 
communicate
>through standard gates.

You are introducing unnecessary complexity. Reiterate. Reiterate. 
Sigh.
LET'S FIRST IDENTIFY THE TYPES OF DATUM THAT WE WILL BE USING. SEE MY 
PREVIOUS
COMM. (14 Dec, 3am)



>   Objects are allocated in a GC-able heap or outside it.

Are you sure you need this? Why not (for example) have each object 
handle its own GC. (ie be given resources, and dispose of them as it
sees fit, returning all to pristine state on exit)?


>that by testing a simple bit pattern of the pointer. The parity bit 
may be
>used to differentiate pointers from integers (thus losing one -- or 
more --
>bit of precision; this trick is very commonly used in LISPs, and in
>caml-light); or the same bit pattern differentiates integers and 
constant
>pointers from GC-able pointers that may be relocated automatically. 
In any
>case, we lose some bit in integers (unless we have enough registers 
to
>completely isolate integers from pointers).

Ideas are good. We can do even better than this.
 Let's agree on data types and then discuss implementation.


>[....]

>> It's not aceptable to have the computer say "I can't understand 
Fred 
>> because I don't have the proper communications drivers"
>Just load them. You can have them together with Fred's stuff.

No, hang on a bit. I'm running on a 486. Fred has a 68030. Jane is 
tinkering with a Z80 just for the hell of it. Fred has a brilliant new
program he has just written. It uses a variety of low level drivers, 
that
work well on his system. Jane and I still need drivers for our system.
Are these drivers:
    A. Local to us?
    B. Written in a common low-level (kernel?) that all systems
        share?
Well? (Or must, gods forbid, Fred keep a copy for all possible 
systems???)


>Ok, so for "Object", say: "a unifying concept that encompasses just 
any
>computing abstraction. Objects are furtherly managed according to 
their
>useful properties, and not according to some unadapted arbitrary
>distinctions".

This is mind-numbingly vague. Whatever happended to inheritance,
encapsulation and polymorphism??




>> I think this open thing is thwarting our attempts to make
>> this thing work fast.
>   Why should it be at all ? I think the opposite.

I agree with Mike. But maybe we can achieve a synthesis.
[...lots of argument about 3-D game engines deleted...]







Part 3. A proposal.
-------------------
Rather than arguing in circles forever, let's:-


1. DEFINE "DATA TYPES"
    a. constants
    b. variables
    c. numbers
    d. blocks
    e. pointers (to blocks)
    f. verbs
    g. interpretable combinations of a..f. ("friends")
    h. objects
    [Please feel free to add or subtract, constructive
        criticism is welcome]


2. DEFINE OUR LLL
    a. symbolic registers, including "pointer registers"
    b. necessary flags
    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
        HOW_LONG
        (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
        ? INSERT into block
        ? EXCISE from block
        ? SEARCH / SORT
    etc....
    [Please feel free to add or ***subtract***, constructive
        criticism is welcome]


3. THEN REFINE.
    a. implementation of data types.
    b. Definitions of objects & how they communicate, in terms
        of the above...
    c. and so on...




Comments?

Bye for now, JVS.


PS. Apologies for the higgeldy-piggeldy text. The text editor I use
@ this end of the world does that sort of thing .. maybe I can tinker 
and fix it.
J.