RE: [sv-bc] FW: Manti 1345, 1711: unique if/case

Sorry, now I am confused.

Essentially what was proposed by Steven and Tom (and I do not object) is
to specify an order allowing only short-circuiting. Then there is no
special consideration of side-effects, and whatever happens happens,
according to the rules. Is it a problem to say that a tool does not have
to check whether there are side-effects, but caveat emptor if you use
them? (Or in other words, you deserve whatever you get.) I don't see
what your objection is anymore.

Regards,
Shalom

> -----Original Message-----
> From: owner-sv-bc@server.eda.org 
> [mailto:owner-sv-bc@server.eda.org] On Behalf Of Gordon Vreugdenhil
> Sent: Monday, November 19, 2007 6:36 PM
> To: Bresticker, Shalom
> Cc: sv-bc@server.eda.org
> Subject: Re: [sv-bc] FW: Manti 1345, 1711: unique if/case
> 
> 
> 
> Bresticker, Shalom wrote:
> > Gord,
> > 
> > Thanks. 
> > 
> > Again I will ask why the LRM has to make an effort to 
> support such a 
> > unique case (not a pun). The uniqueness violation aside, no one has 
> > yet provided a justification for side-effects in case_item 
> expressions 
> > in a unique case.
> 
> Oh, I'm certainly fine with disallowing side effects in 
> unique case completely.  If we want to go that route, the 
> whole issue is moot.
> 
> > I also suggest that statically determinable uniqueness violations 
> > indicate a problem and therefore optimizations don't interest me in 
> > such situations anyway.
> 
> Someone could easily have duplicates due to edge case 
> parameterization, etc. that is never actually reachable in a 
> particular configuration of the circuit.
> 
>  > Plus those should be rare situations and
> > not worth investing in their optimization. And if predictability is 
> > some important, then would it not be more important than 
> optimization?
> 
> Yes, which is why I'm willing to give up optimizations in any 
> cases at all.  The current suggestions already restrict 
> previously valid optimizations.
> 
> Gord.
> 
> 
> 
> > 
> > Regards,
> > Shalom
> > 
> >> Consider the following:
> >>
> >>     unique case (expr)
> >>         1   : ... /* action 1 */
> >>         i++ : ...
> >>         1   : ... /* action 2 */
> >>
> >> I may want to optimize the statically determinable 
> non-unique cases 
> >> and not have to walk through things.  So effectively I may want 
> >> something that looks like:
> >>     case (expr)
> >>         1   :  /* warn */ /* action 1 */
> >>         i++ : ...
> >>
> >> I don't think that would be valid in the approaches that 
> you've been 
> >> discussing and I would object to making such optimizations illegal.
> >>
> >> I do agree that requiring a top-down ordering could be 
> required but 
> >> only until encountering a case that warns.  So once you issue a 
> >> warning, no further evaluation is required and whether 
> evaluation of 
> >> case items which are between the first match and the match which 
> >> conceptually causes the warning is implementation defined.
> >>
> >> I think that gives us a reasonable approach -- if you have a 
> >> well-formed unique case, then you get top-down predictability.
> >> Only when you have an ill-formed case, do you lose some 
> >> predictability.
> >> While I agree with Steven that I don't want to penalize *all* 
> >> side-effects, I don't mind penalizing an ill-formed unique 
> case with 
> >> side-effects.
> > 
> ---------------------------------------------------------------------
> > 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.
> 
> --
> --------------------------------------------------------------------
> Gordon Vreugdenhil                                503-685-0808
> Model Technology (Mentor Graphics)                gordonv@model.com
> 
> 
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> 
---------------------------------------------------------------------
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.