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

-----Non-member submission from [Will Adams <wadams@freescale.com>]
-----
Date: Wed, 02 Aug 2006 11:24:26 -0500

I agree that the formulation is a little involved, but from what I can
understand from the postings at
http://boyd.com/1364_btf/report/full_pr/403.html, this clause was
changed from one which talked about the value of `expression1' directly
to one which talked about a comparison of `expression1' with zero
because the previous version was ambiguous with regard to values of
`expression1' which contain x or z.

Using the logical comparison operators means that these ambiguities are
resolved by the definition of the comparison operators, and do not need
to be addressed again in the definition of the conditional operator. 
This avoids the possibility of creating a definition that treats values
with x and z in a way that is subtly different from the definition of
the comparison operators. The result of a logical comparison is always
0, 1 or X, and so overall I think using the comparison makes for a
simpler definition that is congruent with the rest of the language.

One further potential ambiguity with the current definition of the
comparison operator is that is does not explicitly say that
`expression2' is not evaluated when the condition is 0, or that
`expression3' is not evaluated when the condition is 1. This seems to be
implied by what is said, but that may be me reading into it my
understanding of how I expect the conditional operator to be evaluated.

We are currently using a simulator that evaluates both `expression2' and
`expression3', regardless of the value of `expression1'. I think this is
non-standard behaviour, but I am not certain. It means we cannot use the
conditional operator to rewrite expressions with `&&' or `||' to
guarantee short-circuit evaluation (the same implementation also
evaluates both operands for the logical operators). Perhaps the
definition should explicitly state that only one of `expression2' and
`expression3' is evaluated when the condition is 0 or 1.

will



Bresticker, Shalom wrote:
> While that is correct in principle, what we really want to say is 
> something more easily understandable, along the lines of "If the 
> condition is false (equal to 0)", similar to the original language, 
> while still being accurate.
> 
> "logical inequality comparison of expression1 with zero" is correct, 
> but takes time to figure out what it actually does, and is liable to 
> be misread, as shown by the fact that we made a mistake when 
> formulating it and no one found the mistake till now.
> 
> Shalom
> 
>> -----Original Message-----
>> From: Will Adams [mailto:wadams@freescale.com]
>> Sent: Friday, July 28, 2006 7:02 PM
>> To: Bresticker, Shalom
>> Cc: Brad Pierce; sv-bc@eda-stds.org; michael.burns@freescale.com
>> Subject: Re: [sv-bc] [Fwd: Issues with IEEE 1364-2005]
>>
>> It seems the fix for the definition of the conditional operator is to

>> replace `logical equality comparison of expression1 with zero' with 
>> `logical inequality comparison of expression1 with zero'.
>>
>> will
>>
>>
>> Bresticker, Shalom wrote:
>>> Note that in 1364-2001, the description of ?: was not reversed. It
> was
>>> ambiguous, but not reversed. For a description of how and why it was

>>> changed, see http://boyd.com/1364_btf/report/full_pr/403.html .
>>>
>>> Shalom
>>>
>>>
>>>> I do agree that the description of the condition evaluation in
> 5.1.13
>>>> appears to be reversed.
>>>>
>>>>> On the evaluation of the conditional operator, IEEE 1364-2005,
>>> section
>>>>> 5.1.13 `Conditional operator', states the following.
>>>>>
>>>>>    conditional_expression ::= (From A.8.3)
>>>>>      expression1 ? { attribute_instance } expression2 :
> expression3
>>>>>    expression1 ::= expression
>>>>>    expression2 ::= expression
>>>>>    expression3 ::= expression
>>>>>
>>>>>    The evaluation of a conditional operator shall begin with a
>>> logical
>>>>>    equality comparison (see 5.1.8) of expression1 with zero,
> termed
>>>> the
>>>>>    condition. If the condition evaluates to false (0), then
>>>> expression3
>>>>>    shall be evaluated and used as the result of the conditional
>>>>>    expression. If the condition evaluates to true (1), then
>>>> expression2
>>>>>    is evaluated and used as the result. If the condition evaluates
>>> to
>>>> an
>>>>>    ambiguous value (x or z), then both expression2 and expression3
>>>> shall
>>>>>    be evaluated; and their results shall be combined, bit by bit,
>>>> using
>>>>>    Table 5-21 to calculate the final result unless expression2 or
>>>>>    expression3 is real, in which case the result shall be 0.
>>>>>
>>>>> I am not sure why this defines `condition' as `a logical equality 
>>>>> comparison of expression1 with zero', since this means that
>>>> `condition'
>>>>> is the negation of `expression1' (`expression1 == 0' is 1 when 
>>>>> `expression1' is 0, 0 when it is 1, and X when it is X or Z), and,

>>>>> applying the rest of the definition, when `expression1' is 1, 
>>>>> `condition' is 0, and so `expression3' is evaluated as the result
> of
>>>> the
>>>>> conditional expression. Similarly, if `expression1' is 0, then 
>>>>> `expression2' is evaluated as the result of the conditional
>>>> expression.
>>>>> This seems to give the semantics of an `if else then' operator,
>>> rather
>>>>> than an `if then else', which I doubt is what is intended.
>