Re: JCSP and realtime java processors.

["P.H.Welch" <P.H.Welch@xxxxxxxxx>]

Richard,

Thanks for your interesting mailing!

> ... and we will hopefully attend the next
> meating of WOTUG in the UK. Could anyone tell me when this is?

It's at the University of Reading from 15-18 September, 2002:

  http://www.wotug.org/cpa2002/

Maybe we forgot to tell everyone ... must stop doing that!  I'm copying
this to the occam-com list as well in case ...

> Now we have been given the oppurtunity to be a speaker on the Joint BOF
> sessions at the JavaOne 2002 in San Fransisco, and i would like to
> present some slides on the JCSP programming paradigm. I would like to
> present the benefits of JCSP in multithreaded environments, with respect
> to the difficulty of mutlithreaded applications and synchronization, how
> JCSP resolves some/most of these difficulties and how JCSP lets you
> create well organized and memory controlled applications. Memory and
> Garbage collection is one of the main issues in these embedded

:)

That's great!  You're welcome to use/modify/expand on any of the (Powerpoint)
slides on the JCSP website - i.e.

  http://www.cs.ukc.ac.uk/projects/ofa/jcsp/jcsp.ppt
  http://www.cs.ukc.ac.uk/projects/ofa/jcsp/components.ppt

but please acknowledge us if you do!  Some key points (as to why this model
is simple/clean) are given on slide 10 of the jcsp.ppt.  Referring back to
the JCSP demo game (slide 8) and its implementation (slide 9) immediately
allows intelligent non-programmers to understand its design.  You have to talk
them through slide 9, of course, but then they understand things so well
they start arguing back about the design and how to improve it and extend
it to deal with new features (e.g. collision detection and bouncing).
Tell them that software ain't usually built like that and they're puzzled
and ask how it's really done ...

So you try showing them some UML diagrams and explaining a "standard" Java
monitor/OO design ... that has to cope with a mess such as shown in slide 14
... and they don't believe it!

If you had time, you could talk through slide 109 (or 110 which gives
a slightly different behaviour).  That shows a "real-time sampler" process
ALTing on channel communication and timeouts.  And slides 111-113 that
shows a component that's a PARallel composition of the sampler plus two
other gizmos.

To really scare people, consider slides 10-18 of the components.ppt ...
which shows why the (communicating) process abstraction does not get
into the mess that happens so easily to OO abstractions ... but that's
getting on to really controversial stuff ;) ...

Slide 132 (of jcsp.ppt) summarises things again and also gives an indication
as to why the model fits hardware design so naturally.  The really good
point is that we get a chance to put (process) boundaries around all
our data and to attach processing logic withing each boundary.  That's
why it works, kicks race hazards into touch and is scalable.  It's what
OO always claimed but never really delivered.

> We have been developing realtime java hardware products based on the
> aJile java processor for embedded systems. During this process i have
> been getting quite fond of the architecture proposed by JCSP so we build
> our own subset over the last 3 years. The reason being that we wanted to
> be portable both on the PC with the full Java API, as well as on the
> microprocessor which supports only cldc and has limited memory
> capabilities. At this moment we have a limited version of our JCSP
> library which is running both on the PC as well as on the aJile java
> processor. We have build a HTTP and FTP server based on the limited
> version and the same code runs on both the PC as well as the aJile.

Again great!

Your website also talks about FPGAs.  Have I understood right: for generating
FPGA code you have re-implemented the API, which gives you the CSP/occam model
and (assuming your FPGA implementation is correct) the CSP/occam semantics?
But for the PC, you run the same user code that uses the CSP packages ...
which you seem to have renamed a little?

Incidentally, looking at your "Java to Hardware Compilation" paper from
your (quest-innovations.com) website, I think you're basing your stuff
on CTJ (rather than JCSP?) ... but no matter! :)

You're not alone is this "CSP to hardware" business though.  It's what
occam always should have had, but only recently has with the Celoxica
(handel-c) stuff and the Peel-Cook work reported in CPA 2001 etc.
These ideas are coming of age at last.

Cheers,

Peter.