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

[Johan Klockars <rand@cd.chalmers.se>]

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

I've actually had reason to make use of the comma operator in an
assigment once. This was to get around a strangeness in the compiler
in question, which caused it to emit very non-optimal machine code
unless I forced the value of an expression to a fixed value:
#define reg_w(register_base,offset,value) \
          *((volatile ulong *)(register_base + offset)) = value, 0

A much more common example of the use of the comma operator is in
something like this:
for(i = 0, current = list.head; current; ++i, current = current->next) {

Here the end result of the comma-expressions are not used, and the same
effect could of course be had using separe lines. Using the comma
operator can sometimes make these things clearer, though.

> >   i = (1, 2, 3, 4);
...
> 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.

A comma separated sequence of values in a VHDL assignment is something
very different than in C.

> 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

If someone ever wrote that, it would be as a joke.
Or possibly a test to see if the other programmers really are as good at
C/C++ as they claim to be.  ;-)

> door and fired them on the spot. The code is probably about as redundant as code 

In this case, any half decent compiler would of course get rid of the
unused numbers since they have no side effects.

This is equally pointless, without using the comma operator:
1;
2;
3;
i = 4;
 
> > 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

English, French, German, etc are all languages 'designed' to accomplish
the same task. C/C++ and VHDL/Verilog are not.

> not learn the proper HDL languages (unless they don't want to). You don't get people

Learning the languages is not likely to be the problem.
Learning to think hardware rather than software is.

That is what I think the quote above is refering to.

> 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

A simplistic conversion of C to VHDL/Verilog will not help much.  
Given the code usually emitted by compilers that go from one language to
another, I don't see much hope for anything useful to come from a
simple conversion of a C program (written by a software person) into a HDL.

I certainly wouldn't mind being positively surprised.
However, given that some companies apparently think their software that
does something like this is worth tens of thousands of dollars suggests
that it is not easy to make it actually useful (if it had been, others
would very likely have jumped in and written a program they could sell
for far less and still make huge profits ;-).

> at most give them a running start in developing HDL which will probably lead them into
> learning the HDL as well in time.

It's not the HDL they need to learn, but digital hardware design.

I'm not saying that it is impossible to get some kind of working
hardware out of some kind of C/C++ code. The limitations and extensions
that would be forced upon the language to make this happen makes it
questionable if it's worth it, however (IMHO).

> 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 hope you are aware that VHDL, and probably Verilog (I have never used
that), supports lots of things that are impossible to synthesize into
hardware?

Lots of things that you take for granted in C/C++ simply have no
reasonable implementation in hardware (except for actually implementing
something like a CPU to run a program ;-).

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

Judging by your posts here, I think you need to get a much better
understanding of hardware before you can accomplish that.

-- 
  Chalmers University   | Why are these |  e-mail:   rand@cd.chalmers.se
     of Technology      |  .signatures  |            johank@omicron.se
                        | so hard to do |  WWW:      rand.thn.htu.se
   Gothenburg, Sweden   |     well?     |            (fVDI, MGIFv5, QLem)
--
To unsubscribe from cores mailing list please visit http://www.opencores.org/mailinglists.shtml