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

From: Greg Jaxon [mailto:Greg.Jaxon@synopsys.com]
Sent: Thursday, July 28, 2011 1:29 AM

Steven,
    You describe semantics closer to & and | than to ANSI C && and ||.

I am not sure what you mean by this.

C does not have X states, so the Verilog && and || will certainly be closer to Verilog & and | in the sense that they must deal with X states. But they have the same relationship to Verilog & and | that the C && and || have to the C & and |. Like C && and ||, they reduce each operand to a single bit truth value before applying the & or |, and they short-circuit if the first operand value allows the result to be known in advance. Aside from dealing with X, Verilog && and || match C.

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).

In the old days, short circuiting was being allowed as an optimization, so implementations could skip either evaluation based on the other. The new required short-circuiting of && and || is intended as a convenience for use with new SV constructs, in expressions such as (h != null && h.done). That requires a guarantee of short-circuiting in a particular order.

The new text is not incompatible with the old LRM in the sense that the newly required behavior was always a legal behavior before. This is the same argument that was made in claiming that the rule for when variable initializers execute in SV is compatible with the old rule in Verilog. Some legacy implementations might have to change behavior to comply, just as with the change to initializers. Others might not.

There certainly was no intent to change the resulting value of the expression under any circumstances. Short-circuiting could not and still cannot be performed unless the result of the expression is already known when it takes place.

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.

From the dates, C must have come first. You would have to ask Phil Moorby about his motivations for any changes he made.

Some differences come from the problem domain. Simulation needs to represent hardware that is not in a known state, which led to 4-state logic. So the operators have to deal with X states.

Some differences may address issues with other constructs in the language. If there are expressions in the language that can produce errors or crashes if evaluated, then guaranteed short-circuiting may be more important than allowing implementations complete freedom in optimizing. C had null pointer dereferences, which could crash, and Verilog didn't. Now SV has null handle dereferences, so the situation is more like C.

And with higher-level verification constructs in SV, the people using it are more likely to have SW backgrounds than before, so the issues you raise about consistency with C become more important.

The current definition of && and || is as consistent with C as possible, given that they must handle X states that don't exist in C.

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