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

1. As Brad points out, 1364 does relate to short-circuiting by saying
that an implementation may optionally implement short-circuiting, but is
not required to do so.

2. In the given example,
>    a ? b : c ? d : e
which is parsed as
>    a ? b : ( c ? d : e )

Will says,
" If `a' is 1, then the RH `?:' operator is not evaluated" .

That is not at all clear.
Will himself says,
" The operand evaluation order only really needs to be defined
> when the result of evaluating one operand affects how the remaining
> operands are evaluated."

I don't know what implementations actually do.
But at least in most cases, there is no problem in principle in defining
that the second ?: is evaluated first. If an implementation optimizes by
identifying that it is unnecessary, that is not a problem as long as it
does not change the result.

Shalom



> -----Original Message-----
> From: owner-sv-bc@server.eda-stds.org [mailto:owner-sv-bc@server.eda-
> stds.org] On Behalf Of Brad Pierce
> Sent: Tuesday, July 25, 2006 9:26 PM
> To: sv-bc@server.eda-stds.org
> Cc: michael.burns@freescale.com; WADAMS@freescale.com
> Subject: Re: [sv-bc] [Fwd: Issues with IEEE 1364-2005]
> 
> See http://www.eda-stds.org/sv-ac/hm/2501.html .
> 
> -- Brad
> 
> -----Original Message-----
> From: owner-sv-bc@eda-stds.org [mailto:owner-sv-bc@eda-stds.org] On
> Behalf Of Brad Pierce
> Sent: Tuesday, July 25, 2006 11:20 AM
> To: sv-bc@eda-stds.org
> Cc: michael.burns@freescale.com; WADAMS@freescale.com
> Subject: [sv-bc] [Fwd: Issues with IEEE 1364-2005]
> 
> -----Non-member submission-----
> 
> Date: Tue, 25 Jul 2006 09:19:24 -0700
> From: Michael Burns <michael.burns@freescale.com>
> CC: William Adams <WADAMS@freescale.com>
> 
> Hi folks,
> 
> A comment on precedence definitions in Verilog from one of our
> engineers.
> 
> --Mike
> 
> -------- Original Message --------
> Subject: Issues with IEEE 1364-2005
> Date: Mon, 24 Jul 2006 09:34:24 -0500
> From: Will Adams <wadams@freescale.com>
> To: Michael Burns <michael.burns@freescale.com>
> 
> There is a misstatement in the IEEE 1364-2005 standard, which has been
> there for a while (it was in 1364-2001, and perhaps in earlier
> versions of the Standard). Do you know how to get it fixed?
> 
> The error is in section 5.1.2 `Operator precedence'. There it states
> 
>    All operators shall associate left to right with the exception of
the
>    conditional operator, which shall associate right to left.
>    Associativity refers to the order in which the operators having the
>    same precedence are evaluated.
> 
> This is wrong. It does not make a lot of sense to talk about `the
order
> in which operators ... are evaluated', since I do not think this is
> well-defined in all circumstances (see below). What can be defined is
> the order of _operand_ evaluation.
> 
> This clause confuses associativity, which concerns the parsing of
> expressions that are not fully parenthesized, with evaluation order. I
> think what this may be getting at is that if `a + b + c' is parsed as
> `(a + b) + c', then the LH `+' operator is evaluated before the RH `+'
> operator, since subexpression must be evaluated before a containing
> expression. This definition fails to adequately describe the intended
> evaluation of the conditional operator, which associates
right-to-left,
> but whose operands are evaluated left-to-right.
> 
> The right-to-left associativity of the conditional operator means that
> the expression
> 
>    a ? b : c ? d : e
> 
> is parsed as
> 
>    a ? b : ( c ? d : e )
> 
> and not as
> 
>    ( a ? b : c ) ? d : e
> 
> This is the same as in C, and allows the writing of `if ... else if
...
> else ...' constructs using the conditional operator without excessive
> parentheses.
> 
> However, the conditional operator is evaluated left-to-right. First
the
> condition is evaluated, and then one or both branches is evaluated.
> 
> To see that the order of _operator_ evaluation is not always well
> defined, consider the evaluation of this expression. Operand `a'
(which
> is an operand of the LH `?:' operator) is evaluated first. If `a' is
1,
> then the RH `?:' operator is not evaluated; if `a' is 0, then the
`else'
> expression (ie, `c ? d : e') is evaluated, and its value is the value
of
> the whole expression (ie, of the LH `?:' operator); and if `a' is X or
> Z, then the RH `?:' is evaluated, and its result is combined bitwise
> with the result of evaluating `b' to yield the overall result of the
> whole expression. So, in cases where the RH `?:' operator is
evaluated,
> the evaluation of the LH `?:' operator begins before, and ends after,
> the evaluation of the RH `?:' operator. So what is the operator
> evaluation order?
> 
> I have seen similar mistakes in several C++ textbooks. As far as I can
> tell, it is necessary to have three concepts to clearly define how
> expressions are parsed and evaluated: precedence, associativity, and
> operand evaluation order. The first two together allow the
construction
> of a unique parse tree for any expression, and the third then mandates
> how this parse tree is to be evaluated.
> 
> For most operators, there should be no operand evaluation order. For
the
> expression `a + b', an implementor should be free to evaluate `a'
first,
> `b' first, or both simultaneously, and they should be free to choose a
> different order each time the expression is evaluated, if it suits
them
> to do so. The operand evaluation order only really needs to be defined
> when the result of evaluating one operand affects how the remaining
> operands are evaluated (the only exception to this I can think of is
the
> `,' sequencing operator in C).
> 
> On a related issue, Section 5.1.9 `Logical operators' does not state
if
> `&&' and `||' are evaluated in a short-circuit fashion, as they are in
> C. That is, for the C expression `a && b', `a' is evaluated first,
and,
> if it is 0, `b' is not evaluated, since the value of the expression is
0
> regardless of the value of `b'. If this is not the case, then
different
> coding idioms are required. In C, to test if integer pointer `p' is
> non-null, and points to a positive value, we write `p != 0 && *p > 0'.
> This never leads to segfault, since `p' is not dereferenced if it is
> null. An equivalent expression in SystemVerilog,
> `p != null && p->data > 0' will cause a null object access error if
both
> operands are evaluated when `p' is null.
> 
> Keeping the concepts of associativity and evaluation order separate
> allows for a clearer statement of the requirements. We can distinguish
> `&&', which associates left-to-right, and whose operands (I am
assuming)
> are evaluated left-to-right, from `+', which associates left-to-right,
> but has no required evaluation order. Operator `?:' associates
> right-to-left, and evaluates left-to-right.
> 
> I appreciate that these are minor issues, but I think the Standard
> should be fixed to precisely define the requirements on implementors.
> 
> will