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

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

The `ambiguity' arises from the optional short-circuiting. In
SystemVerilog, evaluation of expression `h != null && h.value == 0' may
or may not involve an illegal dereference of a null object handle,
depending on whether or not the implementation chooses to short-circuit
the evaluation.

I agree that Verilog is not C. But `&&' is a C operator, and it has
well-established semantics, in C and in the languages that have borrowed
this operator from it. Verilog is unique (as far as I know) in borrowing
this operator, but (optionally) changing its semantics.

will


Brad Pierce wrote:
> 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
>>
>>
> 
>