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

["Paul McFeeters" <paul.mcfeeters@ntlworld.com>]

Tobin,

> > 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.

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

> 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!
 
> 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;
> }
> I don't know whether the order of evaluation is specified in this case.

So in equivalent VHDL your statement would interrupt to Webpack as 

ERROR:Xst:827 - C:/test/test.vhd (Line 22). Signal i cannot be synthesized, bad synchronous description.

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. The code is probably about as redundant as code 
can get, you try debugging a large program with masses of redundant code because
the final binary file was too large to run in the memory, probably worst job I 
ever was forced to do.

> 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.

Perhaps, then I suppose you also don't see a need for say English to French or German
to Spanish translation programs either? My program is not an excuse for people to
not learn the proper HDL languages (unless they don't want to). You don't get people
spending years learning a language just to say "what is the time" when they go on
holiday. 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.

I'll give you an actual example, a few weeks ago I tried to explain a hardware
project I would like to develop and market to a company with expertise in this field.
Unfortunately the hardware programmer couldn't understand my level of logic, I can't
express every idea I have as wires and flip-flops as its not my native tongue, my
brain thinks at the C level and expresses itself at the C level. My solutions to the
problems result in a C program which I can now synthesise into Verilog for him which
is easier (and cheaper) than finding an expert in Verilog and C!

I don't expect my translation program to be as tight (efficient) or as fast as pure HDL coding
but I'll try to get it as close as possible. The aim is simply to aid people's developments,
once its translated to Verilog then 'Verilog only' people can work on it and add their magic. 
Given your point I'm surprised you just don't go out and program directly in netlists yourself
(or do you?). Are you sure that the HDL to netlist translators are doing the job right?

Hope it helps,

Paul


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