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

Re: Occam-Tau - the natural successor to Occam-Pi - or is there one already?

I think that the Arduino Plumbing manual is a big step in the direction you want, especially since the current manual does not include the mobile "pi" constructs and is thus very simple to understand. We can brag that it works for a chip with 2KB memory! "Plumbing" is an inspired name, by the way. I hope you can get multiple Arduinos talking, so as to do real projects like a 3D printer.

On Oct 1, 2012, at 2:45 AM, Ian East <ian.east@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

On 1 Oct 2012, at 09:58, Tony wrote:

I came to Occam from programming real time systems in assembler on 2-4k ROM memory systems. What I liked about the simplicity of Occam was that with PAR and PRI I was easily able to describe the things that I had had to write management routines to do previously – the typical car engine controller has foreground tasks driven by the engine turning and background tasks, such as engine temperature, throttle setting.

I wholeheartedly agree. Start them on firmware and microcontrollers - making real things work - kids love this!

 However, I never bought the PRI constructs, especially given two of them.  What I wanted was :

when
  event a then
P
event b then
Q
…

in prioritised order of pre-emption, not PRI ALT or PRI PAR (and certainly not both).  But how do P and Q safely communicate?
(I need to formalise this construct, I know.)

I never found that a problem. The only thing I have no use for is ALT (everything in the real world is PRI ALT; you have to work rather hard to get a fair ALT), but PRI ALT (in a loop) is the exact formalization of the construct you gave.

I am a strong proponent of the Transputer-occam PRI PAR, which addresses a completely different problem from PRI ALT. It is a language feature that embraces both standard "main" code and interrupt code. Most chips enter ISRs with interrupts disabled and remain that way until you IRET, unless you specifically program an STI, and this is just what PRI PAR does. That causes the interrupts to "round-robin" which had better be OK (assuming you are writing "slim" ISRs) because otherwise your event response burden is too much to handle. Bulky "soft" interrupt response code can be in "main" interruptible space, prioritized, almost always, by PRI ALT and booleans.

The beauty of PRI PAR is that interrupt code does not have to be some weird, alien beast that is totally different from "regular" code.


If we want a parallel programming language for kids to learn with, in my view it should be simple and have the basic concepts – ideally we would have a language with two variants – a subset for learning

That is there, in Arduino Plumbing.

and an enhanced version for serious programming.
I don't agree.  First, kids are smart, often too smart.  They'll happily accept something ridiculous.  What they don't do is reflect, especially when they're smart.  Give them C or (worse) Java and you'll never get it away from them again.

If it's simple enough for kids to learn, even when they're not smart, it'll then be safe in the hands of engineers.  If it challenges even the most able engineers, as concurrency does when attempted with C++. C# etc. then I for one will not board that aeroplane.  (It's rather like energy.  If it works in the 3rd world then it's probably sustainable, and thus what we should use too.)

I believe transparency is king.

PERFECTLY STATED! That could be our slogan, really. Combine it with the fact that the real world has concurrency and you are forced to our position.

Larry


The answer to building on what pros need is surely to add layers of abstraction, not to clutter up even the most simple programs with crap.  (I well recall how someone thankfully kept Java out of Year 1 by pointing just what you had to do just to define a constant.)

Ian


Ian East
Open Channel Publishing Ltd.
(Reg. in England, Company Number 6818450)