[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Occam-Tau anyone???

Great idea. I love the way this list has come to life. Brainstorming below...

On Oct 4, 2012, at 3:51 PM, David May <dave@xxxxxxxxxxxxxxxxxxxxx> wrote:

Dear all, 

I would like to see an Occam-like language agreed, defined, 
implemented and promoted in an open process. 

I'm not interested in discussions about how to represent 
priority. There were several very good reasons why this was 
relegated to the 'configuration' section of the original language 
specification. In the meantime, nothing has changed. 

The occam-pi language is an over-extended version of occam 
with no formal specification. Some of the novel features have no 
efficient implementation in message-passing distributed memory

Yes, I agree with you more than with Peter on this. Things are moving toward serial comms and distributed resources (look at PCI --> PCI Express). Memory itself has some serious limitations (e.g. that "parallel" read of a read-only has to really be sequential). I like the idea of a bunch of people snapping pictures of a 2D barcode at once, and the broadcaster knowing they've all grabbed it, so it can be changed. That by itself would eliminate much of the need for shared memory.

So my suggestion is that we start form occam2, and look at what
we need to add from occam3 and occam-pi. What is essential?

(1) Usability on all levels! The original occam development fenced itself in to the Transputer side of the B008. The new occam needs to support an OS; it needs to support scripting; it needs to run on heterogeneous systems and get them to communicate ACCORDING TO ITS MODEL; it needs to support drivers and ISRs; it needs to have ways of communicating with non-occam systems and processes through things like sockets and USB connections, again according to its model. It therefore needs to pay attention to startup and shutdown, which are always the most difficult part of any communicating system.

(2) Dynamic resource appropriation and use. This is the most elementary operation of an OS (type in a program on the bash prompt and run it) yet old occam hid its head from it. It can be accomplished with a SINGLE "wild" heritage (like occam-pi) that spawns multiple, parallel "tame" processes (like strict occam) and then takes back their resources when these are done. Everything is easy, and the resource model is inviolate, if you do this --- and, especially with virtual machines, you get almost all the resource flexibility of a standard, dynamic, spaghetti OS with none of the drawbacks. The OS is then just another program in our language. So are all the drivers. We rule the whole world, just like C.

(3) Strict adherence to the software/hardware equivalence. This allows whatever extensions are consistent with our requirement of true, black-box modularity. One example is the 2D barcode snapshot broadcasting (ACK through closing series switches) mentioned above. Another is "sneakernet" using data containers with return addresses (a limited use of mobile channel-ends consistent with a well-scoped many-to-one channel).

(4) Consistently with (3) in "the other direction", we need component formal verification capability so that we can have an occam software module (simple example: a FIFO) and confirm that a certain hardware implementation is completely consistent in behavior with that software module, and then legally map our program onto hardware that uses the hardware implementation in place of compiled software. Then the sky's the limit in respect of special-purpose efficiency.

The great temptation seems to be to violate (3) and go off after any feature anyone ever advertised as valuable. We need to resist that rigorously, because the real value is more and more applications of (4).

I've been working on language issues for quite a while now - 
mainly looking at how we can really get value out of thousands 
of processors. 

Not sure how best to do this but I'd like to see it happen. I'd be 
happy to host a meeting.

Sign me up! I'll find some funding somewhere ;-)

My belief is that programming the thousand-core chip will prove much easier than people expect, if we properly design our approach along these lines. Therefore we also need (Eric, are you listening?) some examples of realistic but hard problems to design toward with our new features.


Best wishes


On 4 Oct 2012, at 20:38, Rick Beton wrote:

Hi all,

I started the original discussion following Peter's 'Occam Obviously' presentation, but sadly the language discussion petered out, lapsing into a fascinating but many-year-long rehearsed discussions on priority.

My original hope was to seek an answer to this question: if the answer is Occam (obviously or otherwise), what will it take to make Occam generally usable?  In its present form it is not so.

Then there's the question of aspiration versus practicalities.  The first suggestion I made was for packages to be added to Occam-pi and I put it first deliberately.  Not a new suggestion, this; in fact Occam3 had 'modules' way back in 19xx (choose your own xx).  I don't really care for the details of the implementation, I'm much more concerned that Occam-pi/-tau should belong to a busy community, inspired by (a) clarity of thinking and (b) a need to make things happen.

If this is wishful thinking, then alas Occam is not obviously going ever to be more than a teaching tool.

So, what next?