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-Thread: 1089ad,7e78f469a06e6516
X-Google-Attributes: gid103376,gid1089ad,public
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news2.google.com!news3.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!t-online.de!130.59.10.21.MISMATCH!kanaga.switch.ch!switch.ch!newsserver.news.garr.it!newsserver.cilea.it!not-for-mail
From: Colin Paul Gloster <Colin_Paul_Gloster@ACM.org>
Newsgroups: comp.lang.ada,comp.lang.vhdl
Subject: Re: Embedded languages based on early Ada (from "Re: Preferred OS,
 processor family for running embedded Ada?")
Date: 5 Mar 2007 15:36:59 GMT
Organization: CILEA
Message-ID: <eshder$m7l$1@newsserver.cilea.it>
References: <es4dl5$ve2$1@newsserver.cilea.it>
 <pan.2007.03.01.11.23.01.229462@linuxchip.demon.co.uk.uk.uk>
 <113ls6wugt43q$.cwaeexcj166j$.dlg@40tude.net>
 <pan.2007.03.02.11.36.51.700020@linuxchip.demon.co.uk.uk.uk>
 <1i3drcyut9aaw.isde6utlv6iq.dlg@40tude.net>
 <pan.2007.03.03.00.01.49.334@linuxchip.demon.co.uk.uk.uk>
 <1j0a3kevqhqal.riuhe88py2tq$.dlg@40tude.net>
 <camiu2tgii5qvtscjnl84kgr5d8hunu0ej@4ax.com>
 <pan.2007.03.03.13.41.27.542288@linuxchip.demon.co.uk.uk.uk>
 <s44ju2t8ps3v3qo5a7aij025kftk7rk3fo@4ax.c
NNTP-Posting-Host: docenti.ing.unipi.it
X-Trace: newsserver.cilea.it 1173109019 22773 131.114.28.20 (5 Mar 2007
 15:36:59 GMT)
X-Complaints-To: news@cilea.it
NNTP-Posting-Date: 5 Mar 2007 15:36:59 GMT
Xref: g2news2.google.com comp.lang.ada:9686 comp.lang.vhdl:7640
Date: 2007-03-05T15:36:59+00:00
List-Id: <comp.lang.ada>

In news:pan.2007.03.03.17.00.07.159450@linuxchip.demon.co.uk.uk.uk
timestamped Sat, 03 Mar 2007 16:59:52 GMT, "Dr. Adrian Wrigley"
<amtw@linuxchip.demon.co.uk.uk.uk> posted:
"[..]
On Sat, 03 Mar 2007 15:26:35 +0000, Jonathan Bromley wrote:

[..]

> 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.

[..]"


I am not aware of tools which automatically generate such parallel
implementations, though they may exist. For many algorithms a precise
implementation would be required, but for many numerical applications
in which absolute adherence is not required, are such tools so
impressive that they will replace Jacobi's method with the
Gauss-Seidel method (or something even better) without guidance?