Vincent Diepeveen (diep@xs4all.nl) on 2/19/08 wrote:
---------------------------
>David Patterson (pattrsn@cs.berkeley.edu) on 2/15/08 wrote:
>---------------------------
..snip
>>The challenge for this next generation of software to be correct, efficient, and
>>scale with the increasing number of processors, without overburdening programmers.
>>If we as field can succeed at this amazingly difficult challenge, the future looks
>>good. If not, then performance increases we have relied upon for decades will come
>>to an abrupt halt, likely dimishing the future of the IT industry.
>>
>>Dave Patteron, UC Berkeley

There are many different sorts of computing problems. The one most folk seem to expend most effort on is some variant of the computing workload of the PC/workstation/computer, perhaps best (or at least simply) characterised as "Microsoft software" (or "Linux software". The overarching characteristic of this stuff is that it's terribly hard to change (for some mix of a large number of reasons), and that there is a "software product" available separately from a "hardware product" (which leads to the software being designed to be multi-hostable for economic reasons). So lowest-common denominator sets in.

But there's an enormous set of other problems in which the software is part of the product. This is the embedded space, and in many, many areas the space is dominated by cost. If you can knock 10% of the cost of an SoC by rewriting the software, then begod folk will take seriously the necessary rewrite (they won't do it immediately for all the sensible reasons, including "oh? show me it works" and regulatory approval (for example in automotive systems)).

So how could we make embedded chips cheaper? It turns out that even at the el-cheapo end of processor design, a 2- or 3-stage in-order pipeline is quite a lot smaller and lower in power than a 7-stage in-order pipeline. And has much higher ipc, and no need for complex branch-prediction schemes. So you can lower the cost of some SoCs by replacing their single 500 MHz in-order processor with some number of smaller, simpler 250 Mhz processors - and get lower area and lower power and therefore cheaper packaging. And many embedded systems include special-purpose processors of various forms - it'd be nice to be able to swap these in and out to build products at varying price-performance points sans re-engineering the software.

But then you need to program it, and although 'designing and writing parallel code' is something done by tens of thousands of engineers (Verilog is a parallel programming language, albeit nasty, for a particular class of problems) there just aren't any good abstractions-and-compilers available for embedded systems.

So back when I was at Freescale, we took a whack at putting together an simple experimental language that could be of interest. It's 'Plasma', a simple extension to C (and C++) and it's open source. The simplest sound-bite description is "up-to-date occam", if by up to date we mean "does garbage collection and doesn't surprise people who think in C". It comes with examples and wild claims of universal applicability. This implementation is intended to allow the language to be played with, NOT to program lotsa cores - for simplicity, the compiler generates code for a thread library. For industrial deployment, you'd have to build an industrial-strength compiler. But this is fairly simple to change and use.

Look at http://opensource.freescale.com/fsl-oss-projects/

Note that having a language doesn't mean that there is a hardware platform. There are still hard problems to solve at the system and processor architecture levels.

-- Pete