I agree. -----Original Message----- From: Gordon Vreugdenhil [mailto:gordonv@model.com] Sent: Monday, October 02, 2006 2:14 PM To: Francoise Martinolle Cc: sv-bc@eda.org; sv-ec@eda.org Subject: Re: [sv-ec] Re: [sv-bc] operators and data type compatibility rules: mantis item 1608 Francoise Martinolle wrote: > > OK, if the condition is X, the result is always null for class handles. > > Just to make sure I understand equality or inequality comparison, both > expressions below are illegal: > > if (bad == d) // bad and d belong to completely different class > hierarchy Yes, this is illegal. > if (s == d) // s and d are siblings derived classes from the same > base class Yes, this is illegal. I would be fine with allowing this if people felt that things were more regular this way. Of course the only time this condition could be satisfied is when s and d were both null. I don't think that the infix type rule for (s == d) should necessarily be the same as the conditional operator rule for class types. For example, if (1'b1) b = s; else b = d; is valid and it would be unfortunate to have the equivalent expression form ( b = 1'b1 ? s : d ) be made illegal. I would prefer to allow (s == d) than to lose (b = 1'b1 ? s : d). Gord. > > > Francoise > ' > -----Original Message----- > From: Gordon Vreugdenhil [mailto:gordonv@model.com] > Sent: Monday, October 02, 2006 10:51 AM > To: Francoise Martinolle > Cc: sv-bc@eda.org; sv-ec@eda.org > Subject: Re: [sv-ec] Re: [sv-bc] operators and data type compatibility > rules: mantis item 1608 > > Francoise, I don't think that your description is correct in terms of > where the discussion ended up. > > The *result* of an "x" condition in the conditional operator should > always be null for class objects. The question is what the type of > the expression must be. > > I think the discussion ended up with having the following for classes: > 1) if the left and right operands are not the same type then > one must be assignment compatible with the other. Assume > that op1 is assignment comptible with op2 (ie. op2 is some > supertype of op1), then the type of the entire expression > is the type of op2. If neither operand is assignment > compatible with the other, the expression is illegal. > 2) if the condition is x (and the type is valid), the result is > always > null. > > This separates the question of the result value from the question of > the result type which is an appropriate separation. > > Consider the following: > class base; > endclass > class derived extends base; > endclass > > class nogood; > endclass > > base b = new; > derived d = new; > nogood bad = new; > > base result; > > initial begin > result = 1'bx ? b : d; // valid, result is null > result = 1'bx ? d : b; // valid, result is null > > result = 1'b1 ? d : b; // valid, result gets "d" > > d = 1'b1 ? d : b; // illegal; the type of the conditional > // expr is "base" which is not > permitted > // as an assignment to "d" or type > "derived" > // without a cast > > result = 1'bx ? d : bad; // illegal; "d" and "bad" are not > assignment > // compatible in either direction. > end > > > But using assignment compatibility as the rule would not allow: > > class sibling extends base; > endclass > sibling s = new; > > ... > result = 1'b1 ? s : d; > > since neither "derived" or "sibling" is assignment compatible with the > other. > > I don't think this is desirable behavior; I think that we should allow > such conditionals if the two types share a common supertype and that > the type of the result is the nearest common supertype. > > Gord. > > > Francoise Martinolle wrote: > > >>I entered mantis item 1608 to track this issue. >>Once we have concensus, I can prepare a proposal. >> >>Please read and comment. >> >> >> > > ---------------------------------------------------------------------- > -- > >> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf > > Of > >> Francoise Martinolle >> Sent: Thursday, September 28, 2006 10:45 AM >> To: Vreugdenhil, Gordon; Rich, Dave; Steven Sharp >> Cc: sv-bc@eda.org; sv-ec@eda.org >> Subject: RE: [sv-ec] Re: [sv-bc] operators and data type >> compatibility rules >> >> Gordon, Dave, Steve, >> >> I want to enter a mantis item for fixing this issue in the LRM. >> >> So do I hear that the consensus is >> >> 1) for equality == and inequality != operators we require that: >> the class datatypes of left operand and right operand either >> match (this is superseeded by the next 2 rules) >> or that left operand is assignment compatible with right operand >> or that right operand is assignment compatible with left operand? >> >> The rule is that left operand is assignment compatible with > > right > >> operand or right operand is assignment compatible with left. >> >> This means that we cannot compare class handles which are not of >> the same class hierarchy. Is that really what we want? >> >> >> 2) For the conditional operator, if the condition is X we require >> that if the true and false expressions are of class types, >> either the left operand must be assignment compatible with the >> right operand, >> or the right operand must be assignment compatible with the > > left > >> operand. >> >> if the condition is x, and the right operand is assignment >> compatible with the left operand, the result is the left operand > > (base) > >> if the left operand is assignment compatible with the right >> operand, the result is the right operand (base), >> otherwise the result is null (default initialized value for > > class > >> data types). >> >> what about if both left and right have matching class data > > types? > >> which arm do we return? Do we do class handle >> comparison and if they are the same return the class handle >> (result type is the class data type of either arm) >> and if the class handles are not the same, return null (result >> type is irrelevant for null). >> >> Francoise >> ' >> >> >> >> >> > > ---------------------------------------------------------------------- > -- > >> From: Vreugdenhil, Gordon > > [mailto:gordon_vreugdenhil@mentor.com] > >> Sent: Saturday, September 16, 2006 1:12 AM >> To: Rich, Dave; Steven Sharp; Francoise Martinolle >> Cc: sv-bc@eda.org; sv-ec@eda.org; Vreugdenhil, Gordon >> Subject: RE: [sv-ec] Re: [sv-bc] operators and data type >> compatibility rules >> >> >> >> That would be fine with me too. I think that it is overly >> restrictive to require matching, but having a guarantee >> of a common base is sufficient in practice and gives a >> reasonable basis for implementation. >> >> Gord. >> >> -----Original Message----- >> From: Rich, Dave >> Sent: Fri 9/15/2006 9:57 PM >> To: Steven Sharp; fm@cadence.com; Vreugdenhil, Gordon >> Cc: sv-bc@server.eda.org; sv-ec@server.eda.org >> Subject: RE: [sv-ec] Re: [sv-bc] operators and data type >> compatibility rules >> >> > >> > Another solution would be to require one of the expressions >> to have a >> > type that is assignment compatible with the other. > > Whichever > >> one can >> > be assigned from the other (i.e. the base class) is the > > type > >> of the >> > result. >> > >> > >> [DR>] I think this is the best solution. It is also what is >> needed for b==c. The two classes much match, or one has to be > > on > >> an upwards path in the class hierarchy. >> >> > > > -- > -------------------------------------------------------------------- > Gordon Vreugdenhil 503-685-0808 > Model Technology (Mentor Graphics) gordonv@model.com > -- -------------------------------------------------------------------- Gordon Vreugdenhil 503-685-0808 Model Technology (Mentor Graphics) gordonv@model.comReceived on Mon Oct 2 11:18:45 2006
This archive was generated by hypermail 2.1.8 : Mon Oct 02 2006 - 11:18:53 PDT