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

[Tobin Fricke <tobin@splorg.org>]

On Sat, 15 Dec 2001, Paul McFeeters wrote:

> Completely wrong there. A comma denotes a list in C/C++ for example

Although the comma is used to separate arguments passed to a function, the
comma is also a fully legitimate operator, just like +, -, *, etc.

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.

If you doubt this, you can check:


#include <stdio.h>

int main(int argc, char **argv) {
  int i;
  i = (1, 2, 3, 4);
  printf("i = %d\n",i);
  return 0;
}


Note that the parentheses are necessary because "=" binds more tightly
than ",".  In other words, " i = 1, 2, 3, 4; " would be interpreted as
"(i=1), 2, 3, 4".

I don't know whether the order of evaluation is specified in this case.

> int x = 10 ;
> printf ("x = %d, %d", x++, (int) x == 10) ;
> do you get "x=10, 1" (1 is true), or "x=10, 0" (0 is false) ? I personally
> wouldn't guarantee one or the other as its compiler dependent.

The order of evaluation of function arguments is unspecified.  Both
results are thus correct.

On the more general subject of C-to-HDL translation:

I really don't understand your enthusiasm for C-to-HDL conversion.
Computer programming languages and hardware description languages,
although superficially similar, have very different aims.  Hardware really
has no notion of a thread of control, while programming languages center
entirely on that concept.  Software, in its traditional form, is
inherently sequential, while hardware is inherently parallel in operation.

I highly doubt that learning VHDL (Pascal-like) or Verlilog (quite C-like)
is really a barrier to entry for someone who is interested in working with
FPGA's, etc.  Trying to write "computer programs" for FPGA's ignores the
actual nature of that technology and is likely to result in very poor (ie,
inefficient) implementations and engenders a misunderstanding of what the
hardware actually does.

VHDL and Verlilog are well suited to describe systems that consist of
blocks which operate in parallel, connected by "signals," plus
non-synthesizable constructs that are useful in design and simulation. C,
on the other hand, is largely based on linear flow control and pointers
into memory (including "pointer arithmetic"!), concepts which are
ill-suited to hardware design.

Perhaps I am missing a crucial argument, but I do not see why your
proposed C-to-HDL converter is desirable.  The concept to me sounds as if
it is based on a fundamentally flawed understanding of the underlying
technology.  Perhaps if you provide an example of how and when it would be
advantageous to use C for hardware design, I'll better understand the
motivation for C-to-HDL translation.

Tobin



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