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

Hi, Doug,

I'm concerned about forcing side effects.

For synthesis, users like the best quality of results, timing, area,
etc.  In the case that someone codes:

if (f(x) || 1 || f(y))

being able to evaluate it as if (1) and just build the then clause can
reduce the critical path and the area in the design.  The problem also
shows up in a case like:

If (a || b || .... || f(x))

in the event that a is a critical path signal, then there are a lot of
ors that the signal will have to go through to prove that the side
effects of f(x) can happen, putting that side effect now on the critical
path.

K


-----Original Message-----
From: owner-sv-bc@eda-stds.org [mailto:owner-sv-bc@eda-stds.org] On
Behalf Of Warmke, Doug
Sent: Tuesday, August 15, 2006 1:13 PM
To: Brad Pierce; sv-bc@eda-stds.org
Subject: RE: [sv-bc] [Fwd: Issues with IEEE 1364-2005]

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