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

RE: Opportunities for CSP

Thanks Tony,

I used the opportunity to post a comment on their website:

I am very glad to see a renewed interest in true parallel processing
techniques. A good starting point and very pioneering at the time was
Hoare's CSP, later embedded in the transputer followed by the C40 DSP and
SHARC DSP that all had "links". It now time to put them inside the chips as
well. A scalable candidate is SpaceWire (IEEE1355 based) and recently
adopted in an enhanced version as a standard (www.mipi.org) in a consortium
led by Nokia, TI and  ARM. Our contribution is a packet switching based
network-centric RTOS. The distributed version fits in 2 Kbytes. See
www.openLicenseSociety.org. But, as I see it, a major educational effort
will be needed. Software engineers should be taught concurrency and formal
approaches before they are taught the sequential stuff and then concurrency
becomes natural. I recently attended the multicore forum and it was almost
shocking to see how people are now struggling with problems that were solved
25 years ago by the CSP community.


-----Original Message-----
From: owner-occam-com@xxxxxxxxxx [mailto:owner-occam-com@xxxxxxxxxx] On
Behalf Of Tony Gore
Sent: Tuesday, May 15, 2007 10:05 AM
To: occam-com@xxxxxxxxxx
Subject: Opportunities for CSP

I don't know if anyone spotted this post by Ray Simar of TI on EDN.

In it he talks about the problems of interconnect, and says that we need
architectural strategies to deal with it. Specifically he points out that at
the system level it should take into account communication protocols and
their implementation.

Although he is obviously pushing DSP type solutions, he points out that some
of the solutions may come about by going back to the past. If you recall, TI
DSPs eventually gained high speed serial interconnect in response to
competition from the transputer, then perhaps there are other people in the
industry who may be receptive to a rebranded CSP as a solution to the


With the great increase in security issues over the last few years, maybe
now is the time to put some emphasis on other aspects of CSP - the ability
to determine its trustworthiness - it is much easier for CSP systems to be
side effect free. I still find it incredible that so many flaws in today's
software are due to buffer overflows 35 years after they were well
documented in Unix - before most of the programmers creating these buffer
overflows were born.

TCSP - Trusted CSP - would tick a few boxes as a methodology etc for
developing trusted and secure communications - with the problems of security
being mainly in networked systems, and most systems being networked these
days, it is an ideal focus to leverage CSP interest and development.

Best regards

Tony Gore

email  tony@xxxxxxxxxxxx
tel +44-1278-761000  FAX +44-1278-760006  GSM +44-7768-598570
URL: www.aspen.uk.com
Aspen Enterprises Limited
Registered in England and Wales no. 3055963 Reg.Office Aspen House, Burton
Row, Brent Knoll, Somerset TA9 4BW.  UK