Re: CSP for OS?

[tjoccam@xxxxxxxxxxxxx (Lawrence Dickson)]

>Date: Mon, 10 May 1999 09:19:14 -0600
>From: dyke <dyke.stiles@xxxxxxxxxxxxxxxxxx>
>To: occam <occam-com@xxxxxxxxx>
>Subject: CSP for OS?
>
>The following quote is from Bill Joy, one of Sun's founders:
>
>"The glue -- the operating system -- has gone beyond all reason of
>       complexity. NT 5 [Windows 2000] is at 30 to 50 million lines of C/C++
>       code. It's like the Star Wars missile defense system. These kind of
>       programs are just too complex to debug. The tools aren't up to the
>       task."
>
>Has anyone ever worked on operating systems in CSP???

In essence yes. I took DOS and made it "do" occam - including efficient
communications between programs which I've never heard of elsewhere.
(This means robustness of processes with overhead of threads - it seems
to require a non-multitasking OS as foundation.) The paper is in the
PDPTA'96 conference proceedings, p 1010.

>Date: Mon, 10 May 1999 18:28:13 +0100
>From: Richard Beton <rdb@xxxxxxxxxx>
>Organization: Roke Manor Research Ltd
>To: occam <occam-com@xxxxxxxxx>
>Subject: Re: CSP for OS?
>
>dyke wrote:
>
>> Has anyone ever worked on operating systems in CSP???
>
>CSP and compositional semantics are just what's needed for designing a large
>multi-threaded thing like an operating system.

I agree with that but not necessarily with what follows.

>
><MUSE-ALOUD>
>Wouldn't it be really nice to have a new all-dynamic version of occam suitable
>to the task of handling the creation and deletion of all those application and
>service level 'objects' on the fly (surely one of the primary tasks of an OS)!
>Call it occam5. Then, just like C and Unix, everyone would want to do all their
>systems level programming in occam5 and before you knew it, it would become the
>applications language of first choice!
></MUSE-ALOUD>
>
>Rick
>
>PS I chose occam5 because occam1 through 3 are already defined and occam4 has
>been mentioned in the past!
>--

"Dynamic" is scary to me - it means fragmentation and complexity. The
approach I took could be called "locally static" - no fragmentation -
yet it allows a command control interface and even one "wild" program
that does mallocs and things. It is all pretty trivial, which is what
OUR OS should be. Also hardware and software modules are interchangeable
and can be reconfigured at load (not link) time without loss of provable
rigor. Program complexes of arbitrary complexity are built out of programs
of provable simplicity.

Larry