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

[Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>]

On Sat, 3 Mar 2007 12:00:08 +0100, "Dmitry A. Kazakov"
<mailbox@dmitry-kazakov.de> 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.