Re: [sv-ec] Re: [sv-bc] operators and data type compatibility rules: mantis item 1608

From: Gordon Vreugdenhil <gordonv_at_.....>
Date: Mon Oct 02 2006 - 11:14:27 PDT
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.com
Received on Mon Oct 2 11:14:32 2006

This archive was generated by hypermail 2.1.8 : Mon Oct 02 2006 - 11:14:37 PDT