>Thanks. This is the example that I was wondering about. When Shalom >mentioned case_item expression side-effects this didn't make sense. >After I replied I was wondering along the lines of the unique case_item >evaluation. This is one reason why we have different behavior among >different implementations. I know that the definition allows any >case_item to be evaluated in any order if it's unique, but from an >implementation perspective can we do anything to enforce the >implementation evaluation? Or do we just live with these side effects? Some people will say that unique case is intended for synthesizable code where the matching is done in parallel. In that situation, any case item expression with a side effect is incorrect code. Therefore it is OK to specify that the results are undefined in that case. I can sympathize with that view. I am also fine with specifying a reasonable evaluation order that must be followed by a simulator implementation. A synthesis tool can still say that side-effects in a case item expression are not allowed, but the simulation behavior would be well-defined. What I think is a reasonable evaluation order is the following: 1. Case items are evaluated from top to bottom, matching normal case. 2. When a case item expression matches, no further case item expressions for that case item are evaluated. This is for efficiency. 3. After a second case item matches (a uniqueness violation), no further case item expressions are evaluated. This is for efficiency. I could be talked out of number 3, since it only improves efficiency in the situation where there is a uniqueness violation, which should be rare. And implementations might want to provide better error reporting by reporting all the case items that matched. But number 2 is a much more important efficiency concern, and does not affect how many case items matched. Steven Sharp sharp@cadence.com -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Fri Nov 16 16:56:38 2007
This archive was generated by hypermail 2.1.8 : Fri Nov 16 2007 - 19:00:43 PST