RE: [sv-bc] [Fwd: Issues with IEEE 1364-2005]

From: Brad Pierce <Brad.Pierce_at_.....>
Date: Thu Aug 10 2006 - 10:56:13 PDT
I don't see the "ambiguity".  Verilog is not C.  For example, the
context-sensitive arithmetic of Verilog is completely different than in
other programming languages.  Nowhere in the LRM is there even a hint
that && and || behave as they do in C.  In Verilog, as in hardware,
there is no specified evaluation order for operands.

-- Brad   

-----Non-member submission-----
From: Will Adams [mailto:wadams@freescale.com]
Sent: Thursday, August 10, 2006 10:20 AM
To: Steven Sharp
Cc: sv-bc@eda.org; Brad.Pierce@synopsys.COM; michael.burns@freescale.com
Subject: Re: [sv-bc] [Fwd: Issues with IEEE 1364-2005]

I think Steven effectively makes the point I have tried to make in a
couple of previous submissions to this discussion. If someone who has
been involved with the standardization process incorrectly assumes that
the Verilog `&&' and `||' operators are short-circuiting (as they are in
C, C++, Perl, Unix shells, Vera, and every other language I can think of
that uses these symbols for logical conjunction and disjunction), how do
we expect a user of the language to understand that the short-circuit
evaluation is optional, and to write their code to take account of this
semantic ambiguity?

Worse, someone using an implementation of Verilog that short-circuits
the evaluation of these operators likely  will not discover that this is
not guaranteed by the Standard until they try their code on an
implementation that does not short-circuit (or one that does
short-circuit, but with right-to-left, rather than left-to-right,
evaluation of the operands).

The `&&&' short-circuiting conjunction operator seems like a
half-hearted attempt to address the shortcomings of the definition of
`&&'. It can only be used in limited contexts (in the condition of an
`if' statement or a conditional operator, in a label in a pattern
matching `case' statement, or in a timing check definition), cannot be
nested under other operators, and there is no corresponding `|||' for
disjunction. Even if `&&&' was extended to be a general short-circuiting
conjunction, and the corresponding `|||' disjunction was defined, we
would end up with a language where familiar operators (`&&' and `||') do
not have the expected semantics, and unfamiliar operators must be used
instead.

will adams


Steven Sharp wrote:
>> From: "Brad Pierce" <Brad.Pierce@synopsys.com>
>>
>> I think Stu is asking for language that's like that used for && and
||.
>> They are not required to be short-circuiting.  The short-circuiting 
>> is optional only.
> 
> Somehow I thought they were required to be short-circuiting.  My
mistake.
> Too much C coding.  So there currently aren't any operators that are 
> required to be short-circuiting.
> 
> In Verilog, we can get away with not requiring these things to be 
> short-circuiting.  Expression evaluation doesn't produce errors in 
> Verilog, and side-effects are limited to function calls.  It matches 
> the hardware behavior closely, as Stu suggested.
> 
> In SystemVerilog, things like null handle dereferences can produce 
> run-time errors, and there are assignment operators which have side 
> effects.  So there may be a stronger desire for short-circuiting, for 
> use in more software-like code in the testbench.
> 
> Steven Sharp
> sharp@cadence.com
> 
> 
Received on Thu Aug 10 10:56:24 2006

This archive was generated by hypermail 2.1.8 : Thu Aug 10 2006 - 10:56:31 PDT