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.Received on Mon Nov 19 08:38:25 2007
This archive was generated by hypermail 2.1.8 : Mon Nov 19 2007 - 08:39:02 PST