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: Sunday, December 16, 2001 6:56 AM
Subject: RE: [oc] Commas? Concurrent execution in standard C?


> Tobin,
>
> The original argument was C/C++ allowed simultaneous statements as in
simultaneous
> execution which has never been done in ANSI-C.
>

Correct, however when the C (C++) parser (and runtime system) is used
create a new language and if that new language has a concept of simultaneous
execution as well as sequential execution then existing constructs of C/C++
parser must be used to disambiguate simultaneous and sequential operations.
It is my suggestion that the comma operator can be use for this purpose.


> > When the expression "a, b" is evaluated, both "a" and "b" will be
> > evaluated, and the value of the entire expression becomes that of "b".
> > The comma operator binds such that "a, b, c, ..., x" will have the value
> > of x.
>
> And the use of this is? "var = x" seems just so much more practical to me!
>
The description of how an operator works has nothing to do with what is
practical to one particular programmer. The description is simply a rule
that is followed in the event one constructs a statement that would seem
otherwise impracticle.

Function argument evaluation order is an exception to the rule of left to
right evaluation for the comma operator. The reason being was too many
compiler vendors chose differing methods before the ANSI committee
finished this part of the draft. Nobody wanted to budge on their position
and therefore function argument order evaluation was left to be
implimentation dependent.

>
> I checked your code in the MS C++ compiler and  I have to say if any of my
> programming teams in the past had of coded that and then explained to me
> that its functionally equivalent to "i = 4" I would kick them out of the
> door and fired them on the spot.

In C and C++ you have

    for(
        InitStatementAlways;    // one and only one statement here
        Expression1TrueBeforeStatementExecuted; // one statement
        Expression2EvaluatedAfterStatementExecuted // one statement
    )
        StatementToExecute;        // may be multiple statements in braces
{}

If you want multiple initializations you construct the statement with
commas.
If you want multiple operations performed after each iteration you
construct that statemen with commas. Although it is not commonly
used you can also use comma in the evaluation portion of the
statement.

The illustraton of

    x = (1, 2, 3, 4);

Does indeed seem useless. Except for illustrates in the simplest of terms
the concept of the comma operator. Perhaps the following

#ifdef DEBUG_MODE
#define    TRACE_VAL(x) (trace=_LINE_, x)
#else
#define    TRACE_VAL(x) (x)
#endif
    ...
    foo =TRACE_VAL(x);

But the above looks uggly and does not lend any more insight into the
use of the comma operator. A sample use in the for statemen might be
considered more useful but then that exampe might lead you to assume
that the comma operator can only be used in the for statemet.

In the above example you could use a function call at the expense of
having one for each return value and the overhead of the call. Or
you could place a seperate TRACE statement in the program but then
you would loose the ability to trace in other statements

    for(x=TRACE_VAL(0); TRACE_VAL(x)<Limit; TRACE_VAL(++x))
    {
        ...
    }

> Similarly my program will allow people used to C programming (few million
> of us out there at present) to at least express their ideas to hardware
people or
> at most give them a running start in developing HDL which will probably
lead them into
> learning the HDL as well in time.
>

But you realy are not programming in C. You are using C to do your
programming.

The above statement seems to be contradictory. But it is not. Turn the
statemens
around and rephrase for more clarity.

You are using a carefully constructed subset of C, complete with
abstractions not
present in typical C programs, to do your programming. Which results in you
not programming with the full compliment of the C language.

The C programming language does not have the concept of multiplicity
(er... concurrent operations) and it does not have the concept of
"evaluation of expression in progress". You, as the programmer, must
use a set of rules (compatible with C) to synthesize these concepts.
The resultant code will compile with C but it really isn't a C program.
C is used as a cross compiler. For example you might have

    BOOL    doSomething(
        IN    clk,
        IN    signal1,
        IN    signal2,
        OUT    result)
    {
            // do something here
    }

The function runs all the time. Is never explicitly called from any C
statements and the resultant value transitions between TRUE  and
FALSE dependant on the changes to the IN args and the completion
time of the computation of the result.

The functions look like C code. But they do not behave like C
programms.

Jim Dempsey


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