Re: [sv-bc] RE: true/false

From: Greg Jaxon <Greg.Jaxon@synopsys.com>
Date: Wed Jul 27 2011 - 22:37:07 PDT
One other remaining difference we have here vs ANSI C is that they define a "sequence point" after the left operand
evaluation of &&, ||, and ?:.  SV has never formalized these, and eventually the demand may arise to enforce a deterministic
order on side effects separated by these operators.

Greg

On 7/28/2011 12:28 AM, Greg Jaxon wrote:
On 7/27/2011 8:32 PM, Steven Sharp wrote:

AI: File new mantis item to request clarification of Short-circuiting

      of &&, ||, ->, ?: (11.3.5)

 

Comment: what was the issue here?

 

[Whether] X/Z and partially-X/Z values [in the left operand] were treated [exactly like] conditions of if-statements[...].

 

My answer was that it cannot be.   Although && and || are most often used in conditions, where X is treated as false, they can also be used in situations where an X is treated differently from 0.  For example, you can write

 

  cond = b && c;

  $display(“%b”, cond);

 

If b is X, you know the result is not a definite 1.  But you don’t know whether the result is 0 or X until you evaluate c.  If c is 0, then the result is 0.  But if c is nonzero (including X), then the result is X.  So you cannot short-circuit the && if the first operand is X, even though that is treated as false by an if-statement.  You can only short-circuit on a definite false.

 

Steven,
    You describe semantics closer to & and | than to ANSI C && and ||.
I respect that in days of yore, these operators were allowed to decide their result by short cut evaluations,
but that the shortcut rule was symmetric: either operand could make evaluation of the other redundant.
Surprisingly, on this subject the majority preferred to align SV's semantics with ANSI C.
I thought the new text was intentionally incompatible with the original Verilog LRM (and with legacy implementations).

The LRM text in 11.4.7 says “For &&, if the first operand value is logically false then the second operand shall not be evaluated.”  If “logically false” is interpreted as meaning “considered false by an if-statement”, then this is wrong.  If it is interpreted as meaning “definitely logically false, not uncertain”, then it is fine.

 

I agree that 11.4.7 must be reworded to clarify which of these meanings is intended, and both of your replacements are clearer.
A function table would be definitive.

I've always been curious which came first: C's defn or Verilog's. I never learned raw BCPL.
My impression has always been that the original Verilog author(s) felt compelled to never steal whole and outright from C - always to change one or another detail - as if such things might have more than one perfect semantics. In a toy language, quirks are OK, but in
a world of hybrid large systems and portability of coding talent deviations from convention need more justification.

Greg

I think the text for || works either way, since it has to be true to short-circuit.

 

And then we listed -> and ?: because those are specified to short-circuit, and might also have issues.

 

 

Thanks,

Shalom

 

Shalom Bresticker

Intel LAD DA, Jerusalem, Israel

+972  2 589 6582 (office)

+972 54 721 1033 (cell)

http://www.linkedin.com/in/shalombresticker

 

 

---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. Received on Wed Jul 27 22:37:36 2011

This archive was generated by hypermail 2.1.8 : Wed Jul 27 2011 - 22:37:41 PDT