Criticism ... synthesis?

[Mike Prince]

On Sat, 17 Dec 1994, Juliusz Chroboczek wrote:

>   Hi!
> 
>   I'm new to here (I crossed Fare in a lobby last week and had to sign
> on :-) )

Welcome!

> 0. We are sketching the OS of the future.

I'd like to think so =)

> 1. We want to define a set of data structures *in* the system.
>   
>   Yet, we all know that data structures *do* fix the HLL we use, and
> although I have nothing against Lisp, Forth, SmallTalk, Dylan, SML,
> Caml, Scheme, C, C++, C+@, Pascal, Concurrent Pascal, Rascal, Mumps,
> APL, <insert your favorite one here>, I would strongly resent anyone
> trying to force me to use one of these.  I want the freedom to use the
> best language available for my task, and would strongly resent the OS
> I use to limit me.
> 
> 
> 2. We want to define a standard Low Level Language.  This would allow
> us to be portable between systems: let's outlaw machine code!
> 
>   But, by saying LLL, you seem to mix up a few concepts.  Apparently,
> this language would be a portable bytecode as well as the intermediary
> representation for all our compilers, as well as the LLL used by
> humans on our machines (sorta C).
>   Well, designing such a language is quite difficult.  A common
> bytecode for compilers is impossible: for instance, you might want to
> access a variable in one bytecode instruction, and since languages
> have different scoping rules, this precludes the use of a common
> bytecode for different languages.

You can have a common byte code for different languages.  But the code is 
going to be more machinish than HL.

>   Many people have tried to design a common intermediary language for
> compilers, the most recent such project being the GCC compiler.  In my
> opinion, all have failed (for the project is way too ambitious) (the
> Dragon Book, if my memory serves me well, describes a few such projects).
>   Furthermore, if we are to define a common LLL, we must reduce the
> scope of our ambitions,

That is true, we must make some generalizations which may not map as well 
onto certain architectures.  But the code will be able to work on them.

> 3. We want to agree on the architecture.
> 
>   Technically easy (I have very definite opinions on this one, but
> this is not the time to speak them aloud), but politically impossible.
[snip]
>   The third point of view, Software Monarchy, consists in having a
> small amount of privileged code (call it a Kernel), and the rest of
> the system calling the kernel each time it needs to do a privileged
> operation.  This point of view is not very original, and has already
> been implemented, in particular in CMU's Mach.

I think that's where we're going.  With a few twists :)

>   Please do not flame me, but I'd be very surprised if you managed to
> have anything done.

See my other post about that.


>                                    J. Chroboczek

Thanks for the contributions.

Mike