>From: "Brad Pierce" <Brad.Pierce@synopsys.com> >What's the justification for only tightening these two particular >Verilog operators, && and ||? I think there is some justification for it. However, I agree that it would be better to tighten them all up. Not only should && and || be guaranteed to short-circuit, all the other binary operators should be guaranteed not to short-circuit. (As always, an implementation is free to do actual evaluations in any order it likes, as long as it doesn't change visible behavior. So this is really only required when there are side-effects.) >There would still be nondeterminism for all of the other binary >operators in the presence of side-effecting operands, because the >evaluation order of their operands is not specified either. I think the LRM tried to specify this, but I have to concede that it did a poor job. I agree that this should be fixed. Evaluation of operands of all binary operators should be guaranteed to be done left-operand-before-right. >In for a penny, in for a pound. Absolutely. This does still leave the justification of why && and || should be short-circuiting when the other operators are not. Part of this is based on the fact that C (and Vera) work this way. But there are underlying reasons that they work this way. There are common idioms that use && and || and rely on short-circuiting to work properly. Examples have been given of these. I don't know of any such common idioms for the other operators. The logical connectives tend to be used in software-ish situations, where avoiding run-time errors is an issue. The bitwise logical operators tend to be used in hardware-ish situations, where this is not an issue. The special values where short-circuiting can be done for && and || are common (one expects about 50% of the time). The special values where short-circuiting can be done for other operators like + are rare corner cases. So from an simulation optimization perspective, you have allowed short-circuiting where it is most profitable. Steven Sharp sharp@cadence.comReceived on Tue Aug 15 18:40:39 2006
This archive was generated by hypermail 2.1.8 : Tue Aug 15 2006 - 18:40:45 PDT