I do NOT support making short circuiting mandatory...for any operator. It is not hardware behavior, and Verilog is first and foremost a hardware modeling language. Yes, SystemVerilog adds a great number of verification constructs to the language that are not necessarily intended to model hardware. But, just as the RTL synthesizable subset of Verilog grew and evolved over the years, I fully expect that many constructs considered to be just for verification today will also be synthesizable someday synthesizable someday. One of the language compromises that must be made when merging a verification language into a hardware language, is that the verification language is no longer just a software simulation language. In addition, the operators in question were already in Verilog before SV verification was added, as synthesizable hardware modeling operators. The discussion thread has mentioned needing consistent and predictable behavior in software simulation, synthesis, and formal verification. Let's not forget that Verilog and SV are also used by emulators, hardware accelerators, and for prototyping. I think the standard should state that all operations must yield the result of having evaluated all operands, but an implementation is allowed to optimize the evaluation of operands provided it can guarantee the final effect is as if all operands were evaluated, including the effect of any side affects caused by the evaluation those operands. Further, I think that operations such as && and || need to be associative, such that, for example A || B yields the same results as B || A, and A ? B : C yields the same results as !A ? C : B. As a hardware designer, that is the behavior I expect from these operators. I've known for years that software programmers think differently than hardware engineers, and this short-circuiting discussion is further proof of that fact. I will concede that some of the software-like examples supplied show why short-circuiting is relied on in C, such as the example of not wanting to dereference a variable that was not initialized. I submit, however, that a robust implementation can provide the effect of having evaluated all operands, and, at run-time, trap errors such as the dereferencing example. To those software purists involved in this discussion, please remember that hardware does not work the same as software, and that this is we have specialty languages like Verilog and SystemVerilog. If non-hardware like operator behavior is necessary for verification, then lets add new verification operators, rather than break Verilog's synthesizable hardware operators. If this were to come up for vote today, I would vote NO to mandatory short-circuiting on any operator. Stu ~~~~~~~~~~~~~~~~~~~~~~~~~ Stuart Sutherland stuart@sutherland-hdl.com +1-503-692-0898 > -----Original Message----- > From: owner-sv-bc@server.eda-stds.org > [mailto:owner-sv-bc@server.eda-stds.org] On Behalf Of Rishiyur Nikhil > Sent: Tuesday, August 15, 2006 6:13 PM > To: Warmke, Doug > Cc: Brad Pierce; sv-bc@server.eda-stds.org > Subject: Re: [sv-bc] [Fwd: Issues with IEEE 1364-2005] > > Warmke, Doug wrote: > > Does anyone else dissent to establishing conventional > > short-circuiting behavior for || and && besides Brad? > > I, too, would prefer not to define these as short-circuiting. > > While I appreciate a general appeal to be similar to C (a language > that I'm not embarassed to say that I love dearly!), in this issue I > don't agree, because I believe that for SystemVerilog, hardware > intuitions, and not software intuitions of process-based simulation, > should be the driving factor, and it makes much more HW sense to me to > make these operators strict (evaluate both ops) and symmetric (a op b > is same as b op a). > > Also, I suspect that all our friends who hope to write formal > verification tools for SV would prefer a strict, symmetric operator. > > Nikhil > > > Warmke, Doug wrote: > > Well, *avoiding* the side effect of a crash is a good thing. > > > > I think everyone agrees that this functionality can be had in > > various ways. > > > > The point is that short-circuiting is a long and established > > practice in programming. Experienced C programmers rely on > > it all the time, and it's easy to read other people's code > > that relies on it. Reading the ternary operator example > > is tougher... I had to study it a bit to see what was > > going on. > > > > If SystemVerilog establishes short-circuiting in a way > > consistent with C, it will help adoption and appreciation > > of the language by most users. > > > > Does anyone else dissent to establishing conventional > > short-circuiting behavior for || and && besides Brad? > > > > Regards, > > Doug > > > >> -----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, August 15, 2006 1:04 PM > >> To: sv-bc@server.eda-stds.org > >> Subject: RE: [sv-bc] [Fwd: Issues with IEEE 1364-2005] > >> > >> Note that in this example, there are no side-effects in the > >> disjunction. > >> > >> > >> Also, I don't see the big advantage of || vs. ?:. > >> > >> contextList = findContext(scope, name, flags, &remainder); > >> if ( contextList ? remainder[0] != '\0' : FALSE ) { > >> > >> ... > >> > >> -- Brad > >> > >> -----Original Message----- > >> From: Warmke, Doug [mailto:doug_warmke@mentor.com] > >> Sent: Tuesday, August 15, 2006 12:42 PM > >> To: Brad Pierce; sv-bc@eda-stds.org > >> Subject: RE: [sv-bc] [Fwd: Issues with IEEE 1364-2005] > >> > >> Of all the things, I just took advantage of this while > >> writing some code > >> yesterday: > >> > >> contextList = findContext(scope, name, flags, &remainder); > >> if (!contextList || remainder[0] != '\0') { > >> ... > >> > >> "remainder" is not initialized if the function returns NULL. > >> So I don't want to dereference it with [0] in that case. > >> C's short-circuiting disjunction guarantees this won't happen. > >> > >> Regards, > >> Doug > >> > >> > >>> -----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, August 15, 2006 12:28 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] > >>> > >>> What's an example of the usefulness of C's left-to-right > >>> short-circuiting disjunction? > >>> > >>> -- Brad > >>> > >>> -----Original Message----- > >>> From: Will Adams [mailto:wadams@freescale.com] > >>> Sent: Tuesday, August 15, 2006 6:26 AM > >>> To: Brad Pierce > >>> Cc: sv-bc@eda-stds.org; michael.burns@freescale.com > >>> Subject: Re: [sv-bc] [Fwd: Issues with IEEE 1364-2005] > >>> > >>> The `&&&' operator can only appear in limited syntactic > >> contexts. The > >>> following reasonable uses of conjunction are not allowed by the > >>> syntax. > >>> > >>> c = a &&& b ; > >>> if ( ! ( a &&& b ) ) > >>> > >>> The second of these is a problem because there is no `|||' short > >>> circuiting disjunction, and the syntax does not allow this > >> operation > >>> to be expressed with `!' and `&&&'. > >>> > >>> If `&&' is not required to have short-circuit evaluation, > >> and `&&&' is > >> > >>> suggested as an alternative for cases where short-circuiting is > >>> desired, we have a situation where a familiar operator has > >> unfamiliar > >>> semantics, and the familiar semantics are only available > in limited > >>> contexts from an unfamiliar operator. > >>> > >>> will > >>> > >>> > >>> Brad Pierce wrote: > >>>>> It sounds like '&&&' is not appropriate to use as a > >> general-purpose > >>>> short-circuit > >>>>> logical AND. > >>>> Because &&& allows the > >>>> > >>>> expression 'matches' pattern &&& ... > >>>> > >>>> syntax, it can do *more* than a general-purpose > >>> short-circuit logical > >>>> AND. How does its greater generality make it inappropriate > >>> for a more > >>> > >>>> restrictive purpose? > >>>> > >>>> Regardless of the original reasons for introducing > >>>> > >>>> if (expression &&& expression) > >>>> > >>>> it behaves exactly like C users have come to expect from > >>>> > >>>> if (expression && expression) > >>>> > >>>> . > >>>> > >>>> -- Brad > >>>> > >>>> -----Original Message----- > >>>> From: Steven Sharp [mailto:sharp@cadence.com] > >>>> Sent: Monday, August 14, 2006 2:43 PM > >>>> To: Brad.Pierce@synopsys.COM; nikhil@bluespec.com > >>>> Cc: wadams@freescale.com; sv-bc@eda-stds.org; > >>>> michael.burns@freescale.com > >>>> Subject: Re: [sv-bc] [Fwd: Issues with IEEE 1364-2005] > >>>> > >>>> > >>>>> From: "Rishiyur Nikhil" <nikhil@bluespec.com> > >>>>> '&&&' is not merely a conjunction operator, and its reason for > >>>>> existence is not to introduce short-circuiting-- it is > >>> because it has > >>> > >>>>> a > >>>>> variable-binding function unique to the pattern-matching > >>> facilities > >>>>> of the language. > >>>> Thanks for the explanation. It sounds like '&&&' is not > >>> appropriate > >>>> to use as a general-purpose short-circuit logical AND. > >>>> > >>>> Steven Sharp > >>>> sharp@cadence.com > >>>> > >>>> > >>> > >> > > >Received on Tue Aug 15 22:22:53 2006
This archive was generated by hypermail 2.1.8 : Tue Aug 15 2006 - 22:23:05 PDT