Re: For the love of CSP ...

[tjoccam@xxxxxxxxxxxxx (Lawrence Dickson)]

All,

May I enter this discussion as one with some experience (writing
for Linux and dealing with, and watching my colleagues deal with,
open-source code.)

Just to paint the picture, here's the time-machine "if only":
If only the original releases of the Transputer and occam had included
wide-ranging occam tools targeted to the PC... if only the
Transputer's technical success had driven a ferment of open-source
gcc-like occam development for ALL other chips... if only such
wide-ranging operating-system-free communication capability had
STUNTED THE GROWTH of operating systems which are now insanely stiff
and bloated (as the Internet and distributed computing is finally
starting to do, fifteen years late).

Here's the upside: "Ring 0" development (interrupts, drivers, cached
data flow) has become almost impenetrably stiff to develop, even
under open source systems like Linux, so people tend to give up in
despair and accept whatever botches the OS offers, and work only on
top of it. As all of us remember, the Transputer and TRAMs made such
work (SCSI drivers etc) a fluff job - and it was pretty easy under
DOS too.

We could offer a solution...

>From: Roy Wilson <designrw@xxxxxxxxxxxxxxxx>
>Date: Mon, 09 Oct 2000 01:02:15 GMT
>Message-ID: <20001009.1021500@xxxxxxxxxxxx>
>Subject: For the love of CSP ...
>To: java-threads@xxxxxxxxx
>
>Hi, all!
>
>My original msg went to Adrian alone. Given the modest proposal I'm
>making, I'm forwarding his response to mine.
>
><SNIP>
>
>> > Most of the programmers I've worked with want proof by example: that is,
>> > examples of large-scale programs/systems written without undue mental
>> > anguish :-). It seems to me that this could be supplied, for example by
>> > converting the KROC based web-server to JCSP and commercializing it - or
>> > at least sticking it in people's faces (just kidding) - along with
>> > performance numbers ala ApacheBench (not unlike those provided by Zeus).
>> >
>
>> The "proof/demonstration" that the methods work on large problems is somewhat
>> different. I think that we have examples, but given the small underfunded
>> CSP efforts, it is hardly surprising that we can't display many industrial
>> examples. Chicken and egg. Of course, such examples are crucial. My own
>> feeling is that we need more automatic tools both to solve bigger problems,
>> and to make the methods more accessible to ordinary users. Almost everything
>> has been done by small isolated groups and often individuals working in
>> academia with virtually zero funding. It is amazing what has been achieved
>> with such limited resources and with so much discouragement. It is because
>> the approach is so elegant and powerful that it engenders enthusiasm
>> once one has understood properly.
>
>Here's the modest proposal: How about open source development? KROC is
>already almost open source (depending how you construe that phrase).
>Might not a (not so ragtag) scattered band of CSP aficionados cobble
>together a CSP-rendition of KROC on a par with Apache? If not professors,
>then undergraduates eager for fame! "All" it takes (he said naively) is
>a site at www.sourceforge.com.
>
>Roy

My suggestion for an open-source development (I'll talk X86 but it would
apply to any chip):

(a) A 32-bit DOS-like OS that, as DOS did, opens up Ring 0 to programs,
not just kernels; is similarly anarchic; but offers hooks so that the
careful programmer can embed cooperative program status information in
each process instead of centralized. This keeps the OS tiny. It would
not even be explicitly multitasking, but a smart process could arrange
multitasking loads itself; I did this in DOS.

(b) An occam compiler that would generate smart processes of the above
sort, and work in concert with a C compiler that would be smart about
dynamic stuff. One dynamic heritage can run amongst many static parallel
programs (these take the place of drivers, ELIMINATING THE STIFFNESS).

This all runs in Ring 0, so taken together, it can be characterized as
a means of writing a reconfigurable and understandable kernel from
scratch, easily. It could underlie a whole other set of "standard" user
code programming, if desired. Or function as an easy, modular RTOS.

Of course, our snappy, bottom-level, kernel-like stuff would also have
hardware ports and channels and thus be able to communicate with all
other devices on the bare-metal level, without being trapped in stiff,
over-engineered software protocols and drivers. In my opinion, nothing
more is needed than the two-priority, round-robin interrupt system of
the Transputer. Real-world slowness is from ill-adapted kernel
buffering schemes, which we brush aside.

This is the kind of thing that was easy fifteen years ago and now is
almost impossibly hard. But the assembly-level hardware protocols are
little changed in difficulty. We could walk into the gap and take it
over. People who want to reconfigure bottom-level data flows could,
I guess, save 90% of their effort using our tools. We could be to
all the RTOS's what Linux is becoming to the bloat-OS's.

Larry Dickson