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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no 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!news1.google.com!news.germany.com!solnet.ch!solnet.ch!news.clara.net!wagner.news.clara.net!nntp-peering.plus.net!ptn-nntp-feeder01.plus.net!ptn-nntp-spool01.plus.net!ptn-nntp-spool02.plus.net!ptn-nntp-reader02.plus.net!not-for-mail From: Jonathan Bromley 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: Sat, 03 Mar 2007 11:27:50 +0000 Organization: Doulos Ltd Reply-To: jonathan.bromley@MYCOMPANY.com Message-ID: References: <113ls6wugt43q$.cwaeexcj166j$.dlg@40tude.net> <1i3drcyut9aaw.isde6utlv6iq.dlg@40tude.net> <1j0a3kevqhqal.riuhe88py2tq$.dlg@40tude.net> X-Newsreader: Forte Free Agent 3.1/32.783 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit NNTP-Posting-Host: 23486af8.ptn-nntp-reader02.plus.net X-Trace: DXC=81HTb5j?8Sm2HSD]`WN8?migd3Y`7Rb;n37XnI;[OUCdG`jPeGcW;ikj5omoli3R0fM?hO4aZFXDd=Ri@042oKnk X-Complaints-To: abuse@plus.net Xref: g2news2.google.com comp.lang.ada:9652 comp.lang.vhdl:7616 Date: 2007-03-03T11:27:50+00:00 List-Id: On Sat, 3 Mar 2007 12:00:08 +0100, "Dmitry A. Kazakov" wrote: >Because tasks additionally have safe synchronization and data exchange >mechanisms, while PAR should rely on inherently unsafe memory sharing. The PAR that I'm familiar with (from CSP/occam) most certainly does *not* have "inherently unsafe memory sharing". There seems to be an absurd amount of wheel-reinvention going on in this thread. >> The semantics I want permit serial execution in any order. And permit >> operation even with a very large number of parallel statements in >> effect. Imagine a recursive call with each level having many parallel >> statements. Creating a task for each directly would probably break. >> Something like an FFT, for example. FFT the upper and lower halves >> of Thing in parallel. Combine serially. > >Yes, and the run-time could assign the worker tasks from some pool of, >fully transparently to the program. That would be very cool. And easy to do, and done many times before. >> The compiler should be able to generate code which generates a >> reasonable number of threads, depending on the hardware being used. > >Yes For heaven's sake... You have a statically-determinable number of processors. It's your (or your compiler's) choice whether each of those processors runs a single thread, or somehow runs multiple threads. If each processor is entitled to run multiple threads, then there's no reason why the number and structure of cooperating threads should not be dynamically variable. If you choose to run one thread on each processor, your thread structure is similarly static. Hardware people have been obliged to think about this kind of thing for decades. Software people seem to have a pretty good grip on it too, if the textbooks and papers I've read are anything to go by. Why is it suddenly such a big deal? >> Maybe you're right. But I can't see how to glue this in with >> Ada (or VHDL) semantics. In VHDL, a process represents a single statically-constructed thread. It talks to its peers in an inherently safe way through signals. With this mechanism, together with dynamic memory allocation, you can easily fake-up whatever threading regime takes your fancy. You probably wouldn't bother because there are more convenient tools to do such things in software land, but it can be done. In hardware you can do exactly the same thing, but one (or more) of your processes must then take responsibility for emulating the dynamic memory allocation, carving up some real static physical memory according to whatever strategy you choose to implement. >That is the most difficult part! (:-)) Maybe. But then again, maybe organising the structure of the actual application is the most difficult part, and this vapid rambling about things that are already well-understood is actually rather straightforward. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.