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

Brad Pierce wrote:
 > -----Non-member submission-----
 > From: Will Adams [mailto:wadams@freescale.com]
 > Sent: Thursday, August 10, 2006 10:20 AM
 >    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.

There are specific reasons for these language design choices.

'&&&' is not merely a conjunction operator, and its reason for
existence is not to introduce short-circuiting-- it is because it has
a variable-binding function unique to the pattern-matching facilities
of the language.

If the left-hand operand is matching pattern, then it can also
introduce and bind identifiers from the pattern in the left-hand
operand, which are then in scope and available in the right-hand
operand and in the 'then' part of the conditional.  This is the reason
why:
  - it is only at the top-level of conditionals (if it was nested more
    deeply, what would be the scope of the pattern variables?)

  - it is assymmetric, left-to-right (the pattern variables in the
    right-hand operand only make sense if the left-hand match succeeds)

  - there is no corresponding '|||' (again, the pattern variables in the
    right-hand operand only make sense if the left-hand match succeeds)

Nikhil


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