Re: PAR (Was: Embedded languages based on early Ada)

["Randy Brukardt" <randy@rrsoftware.com>]

"Dr. Adrian Wrigley" <amtw@linuxchip.demon.co.uk.uk.uk> wrote in message
news:pan.2007.03.06.13.19.20.336128@linuxchip.demon.co.uk.uk.uk...
...
> The problem with an Ada intermediate is that you can't easily translate
> programs with "par" into a language without.  There is no
> realistic work-around or simulation of the execution behaviour of par.
> Par says "create a thread if it looks appropriate at this moment".
> The expectation is that this generates the appropriate concurrent
> call instruction.  Maybe some major compiler hacking and special
> directives could patch something together, like Cilk does for C.

Yes, of course. But how, precisely, this is mapped to Ada (or even if it is
mapped to Ada) isn't particularly relevant. The reason for the suggestion
is: (1) It's relatively easy to get something running; (2) there isn't any
existing hardware or OS that can take advantage of fine-grained parallelism.
Your point is about breaking the software end of that problem, but that will
have to be executed in a conventional way for now. Maybe at some point in
the future the programs can execute with more parallelism, and at least then
the programmers would not have to change habits to do so; (3) by assuming
that a full Ada implementation is underlying, the program will be able to
use all of Ada, without having to define the semantics of that. You can
concentrate solely on the new stuff, with a fair presumption that the rest
will "just work".

> One aspect of this discussion is the inaccessability of fine-grain
> concurrency to either a harware developer or a software developer.
> As a processor designer, I can see how to implement concurrent
> calls and concurrent memory access - but doing this does not help
> run any existing code.  As a programmer, I can see where my code
> is logically concurrent, but the language denies me this expressiveness,
> and my processor doesn't support it.  Some leadership is needed!

Exactly my point; by allowing this to be written and then mapped
conventionally, programmers can get used to the idea of specifying
fine-grained parallelism (preferably with checking!), without having to
invest in all new (and thus buggy) systems. One hopes that would provide a
way to break the Gordian knot. Trying to convert all at once is never going
to work.

                                       Randy.