Re: Embedded languages based on early Ada (from "Re: Preferred OS, processor family for running embedded Ada?")

["Dr. Adrian Wrigley" <amtw@linuxchip.demon.co.uk.uk.uk>]

On Sat, 03 Mar 2007 15:26:35 +0000, Jonathan Bromley wrote:

> On Sat, 03 Mar 2007 13:40:16 GMT, "Dr. Adrian Wrigley"
> <amtw@linuxchip.demon.co.uk.uk.uk> wrote:
> 
>>  What syntax do I use, and which
>>compiler, OS and processor do I need to specify and exploit
>>fine-grain concurrency?
>>
>>In 1987, the answers were "par", Occam, Transputer. Twenty
>>years later, Ada (or VHDL, C++, C#), Linux (or Windows), Niagara
>>(or Tukwila, XinC, ClearSpeed, Cell) do not offer us anything
>>remotely similar.  In fact, in twenty years, things have
>>got worse :(
> 
> Absolutely right.  And whose fault is that?  Not the academics,
> who have understood this for decades.  Not the hardware people
> like me, who of necessity must understand and exploit massive 
> fine-grained parallelism (albeit with a static structure).  No, 
> it's the programmer weenies with their silly nonsense about 
> threads being inefficient.

By the way... I am a satisfied customer of yours (from 1994).

If there is any blame to share, I place it upon the language
designers who don't include the basics of concurrency (and
I include Ada, which has no parallel loops, statements or function
calls.  Nor decent pure functions).

I do hardware, processor and software design.  But I'm not
keen on trying to fix-up programming languages, compilers
and processors so they mesh better. (Unless someone pays me!)

> Glad to have got that off my chest :-)  But it's pretty frustrating
> to be told that parallel programming's time has come, when

(I'm not saying this - so don't be frustrated!  What I'm saying
is that multithreading has become "buzzword compliant" again,
so may there's an opportunity to exploit to address longstanding
technical deficiencies and rebrand Ada and/or VHDL)

> I spent a decade and a half trying to persuade people that it
> was worth even thinking about and being told that it was
> irrelevant.

Parallel programming's time hasn't quite arrived :(
But it's only 3-5 years away!  Still. (like flying cars,
fusion power and flat screens, which never seem to get
nearer. {Oh. tick off flat screens!})

> For the numerical-algorithms people, I suspect the problem of
> inferring opportunities for parallelism is nearer to being solved
> than some might imagine.  There are tools around that
> can convert DSP-type algorithms (such as the FFT that's 
> already been mentioned) into hardware that's inherently

Again, this is ages old now.  But it can't convert
C-type programs reliably and efficiently.

> parallel; there are behavioural synthesis tools that allow
> you to explore the various possible parallel vs. serial 
> possibilities for scheduling a computation on heterogeneous
> hardware.  It's surely a small step from that to distributing 
> such a computation across multiple threads or CPUs.  All 
> that's needed is the will.

A small step. Like from Apollo 11.

Once the language/software/compiler/processor deadlock is broken,
things will move rapidly.  Give it another 15 years, and we might
be half way there.

Glad to see that we're not so far apart as I thought!
--
Adrian