From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,1a44c40a66c293f3 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news1.google.com!news.germany.com!news.ecp.fr!news.jacob-sparre.dk!pnx.dk!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: PAR (Was: Embedded languages based on early Ada) Date: Tue, 6 Mar 2007 17:49:32 -0600 Organization: Jacob's private Usenet server Message-ID: References: <1172192349.419694.274670@k78g2000cwa.googlegroups.com> <1172239820.896603.222120@k78g2000cwa.googlegroups.com> <113ls6wugt43q$.cwaeexcj166j$.dlg@40tude.net> <1i3drcyut9aaw.isde6utlv6iq.dlg@40tude.net> <1c61jqeqo68w$.2irtg70stnsa.dlg@40tude.net> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: jacob-sparre.dk 1173224871 12633 69.95.181.76 (6 Mar 2007 23:47:51 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Tue, 6 Mar 2007 23:47:51 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Xref: g2news2.google.com comp.lang.ada:9734 Date: 2007-03-06T17:49:32-06:00 List-Id: "Dr. Adrian Wrigley" 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.