Re: [oc] Commas? Concurrent execution in standard C?

["Jim Dempsey" <dempsey@northnet.net>]

----- Original Message -----
From: "Paul McFeeters" <paul.mcfeeters@ntlworld.com>
To: <cores@opencores.org>
Sent: Saturday, December 15, 2001 5:07 PM
Subject: [oc] Commas? Concurrent execution in standard C?


> Jim,
>
> firstly you are wrong mate, secondly thanks.
>
> > Note the use of comma "," instead of semicolon ";". In C/C++ statements
> > occur in the logical order that is equivalent to the order in which they
are
> > written.
>
> Completely wrong there. A comma denotes a list in C/C++ for example
>
> enum {one, two, buckle, my, shoe} // List of identifiers to be enumerated
> printf("Hi Jim %d%c%l", int, char, long) // List of parameters to be
passed to func
>

for(i=0,j=3,k=15;   i<10;   ++i, j+=3, k+=5)
    foo(i,j,k);

In the above example, the comma denotes an operation seperator for
expressions that are evaluated within one statement.

Note, also you can use comma within the body of a program

    foo = fee;
    ++fi, ++fum, zulu = able + baker, omega = omigon;

The above represents two statements.

Therefore, there is a need in the C to VHDL for an indication of
simulteaneous operation. I believe that these are done with
a pseudo function call (a real call during simulation).

> A semi-colon denotes the end of a statement and I suppose you could
surmise
> it also infers a sequential operation of those statements. There is no
guarantees
> in C/C++ as to how the assignments in a list will be executed although
most
> people assume its in "top down" fashion. Quite a few compilers work in a
> "bottom up" fashion as its easier, I'll explain for anybody interested.

Otherwise knowns as conversion of C/C++ statement to RPN
(Reverse Polish Notation).

> > When using semicolon you specify a logical order of sequence of
> > operation. When using comma you specify that the operations _logically_
> > appear to occur at the same time but can be ordered arbitrarily.
>
> Second part now, thanks I was thinking the other day whilst working on the
> C++ to Verilog translator about the sequential alterations I was going to
do to
> "vanilla C" in order to support the sequential nature that implementation
in
> FPGAs could allow the C++ program. Handel-C uses
>
> par
> {
> function1() ;
> function2() ;
> }
>
> to permit you to run the two functions in parallel. So now after your
slightly
> wrong assumption I'm thinking about using commas at the end of statements
instead
> of semi-colons to signify the instructions are in a kind of "parallel
list" rather
> than sequential statements e.g.
>
> function1(),
> function2(),
> function3() ;
>
> So now all 3 functions will run concurrently when compiled with my
program. Still
> debating this with myself (just me, myself and I so no deadlocked votes)
which to
> use. Anybody want to vote for either out there? Let the public decide
time, all
> C programmers which do you prefer?
>

I looked up the comma operator in both Borland and Microsoft C/C++
manuals. Both state that the order of operation is left to right. But both
also state that the comma operator can be used for  groupings where
a single statement is expected (e.g. in the for( statement).

However, the converter is an abstraction of the language (C to VHDL).
There needs to be a means of differentiation of what happens asynchronously
from what happens synchronously, from what happens sequentialy.
The first two of the differentiations are not part of the C/C++ coding
excepting for the writing of interrupt functions and/or constructors in C++.
Interrupt functions are event driven but must be written following some
restrictive rules (e.g. you cannot allocate from a heap where the allocation
routine is not written with reentrancy provisions).

Furthermore, the converter abstraction should handle

    A = B + C;  // AdderOut = AdderIn1 + AdderIn2

Where the value of A is undefined until some time after B and C become
stable. C and C++ have the concept of instruction dwell times where
the dwell time is always sufficient for the operation to complete.
The conversion language would find it benificial NOT to have this
restriction. (Although this will confuse many traditional C programmers.)

Jim Dempsey






--
To unsubscribe from cores mailing list please visit http://www.opencores.org/mailinglists.shtml