RE: [sv-ec] RE: [sv-bc] SV-BC 291 is uploaded and ready

Surrendra,

Is it possible there is some misinterpretation of "source_t" and
"dest_t"?
The correct interpretation is that "dest_t" refers to a TYPE to which a
cast should convert a value. There is no particular object associated
with "dest_t", for example the lhs of an assignment or comparison.
"source_t" is the TYPE of the object which is being cast.

Legality of assignment or comparison operations should be determined
*after* any cast has been performed, not during the cast operation.

One other point in this debate is that I haven't seen any viable
alternatives to the changes SV-BC approved for #111. If you can
come up with a viable alternative that guarantees 100% consistent
behavior between implicit and explicit casts, I think everyone who
voted to pass 111 would take a serious look at such a proposal.

Regards,
Doug

________________________________

        From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf
Of Rich, Dave
        Sent: Wednesday, November 17, 2004 9:29 AM
        To: Surrendra Dudani; sv-bc@eda.org; sv-ec@eda.org
        Subject: RE: [sv-ec] RE: [sv-bc] SV-BC 291 is uploaded and ready
        

        Surrendra,

        What about this case where type_A has a dynamic type)

        if (var_of_type_A == type_A'(var_of_type_B) )...

         There is no LHS to use in a size comparison.

        The sizes in the text you quoted are referring to possible sizes
that the type will allow. i.e. is there an allocated size for the type
that would exactly match the number of bits in the source expression. In
the LRM example at the end of the section, Stream is initially an empty
queue of bits.

        Again 291 has nothing to do with the type equivalence
requirements.

        Dave
        ________________________________

                From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org]
On Behalf Of Surrendra Dudani
        Sent: Wednesday, November 17, 2004 5:26 PM
        To: sv-bc@eda.org; sv-ec@eda.org
        Subject: RE: [sv-ec] RE: [sv-bc] SV-BC 291 is uploaded and ready

        Hi Dave,
        My reasoning is based on a strong statement from the LRM as
follows:
        
        "If both source_t and dest_t are fixed sized unpacked types of
different sizes then a cast generates a compile-
        time error. If source_t or dest_t contain dynamically-sized
types then a difference in their sizes will
        generate an error either at compile time or run time, as soon as
it is possible to determine the size mismatch."
        
        This leads me to believe that, at least when dynamic types are
involved, bit stream casting is not just an expression as the bit length
of any type containing a dynamic type is undefined. The actual value of
the LHS of the assignment has to be considered to make it work.
        
        There are additional differences between type equivalence
consideration and bit-stream cast. The former does not permit
2-state/4-state differences, while bit-stream cast does conversion. Two
dynamic types may be equivalent, but not bit-stream castable. Bit-stream
cast is not defined for some data types such as real and class.
        
        Therefore, I agree with Mark that bit-stream casting is very
different than the casting used for type conversion in assignments.
        
        The restrictions in 291 force users to think of unpacked arrays
as packed arrays. Type equivalence requirement for elements is too
severe for assignments of unpacked types.
        Surrendra
         
        
        
        At 04:05 PM 11/16/2004 -0800, Rich, Dave wrote:
        
        
        

        Hi Surrendra,
        
         
        
        The behaviors you are describing have to do the greedy nature of
bit stream casting. I admit this may be an issue, but 291 has nothing to
do with it. And to address MarkH concerns, voting down 291 does not
repeal 111, and neither changes the greedy nature of bit-stream casting.
Away to change this would be to say that casting to an equivalent type
was not greedy, but instead preserved the dynamic sizes.
        
         
        
        Also, a bit-stream cast, or any cast for that matter, is just an
expression. The type or the contents of the LHS of an assignment have no
effect on the cast. I don t think the previous contents of the LHS have
any effect on any assignment. (Except in determining whether an element
an associative array already exists). See more comments below
        
         

        ________________________________

                From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org]
On Behalf Of Surrendra Dudani
        Sent: Tuesday, November 16, 2004 6:33 PM
        To: sv-bc@eda.org; sv-ec@eda.org
        Subject: Re: [sv-ec] RE: [sv-bc] SV-BC 291 is uploaded and ready
        
         
        
        Hi Dave,
        I apologize for making a typo in the example. It should have
been
        a = dest_t'(b); (1)
        
        Since the rules of unpacked structure assignment are not clearly
stated, let me give some examples of unpacked array assignment with
string as the type of the element. The elements of the lhs and rhs
arrays are of equivalent type, but of different lengths.
        
        typedef string source_t[2];
        typedef source_t dest_t;
        
        source_t a;
        dest_t b;
        
        a[0] = "ab";
        a[1] = "c";
        b[0] = "defg";
        b[1] = "hijk";
        
        b = dest_t'(a); (1)
        b = a; (2)
        (1) is illegal, as the lhs bit length is different than rhs bit
length
        
        This is legal. b[0] = abc ; b[1]= ;
        (2) is legal, since each element is equivalent and the array
lengths are equal
        
        Yes. b[0] and b[1] will be resized.
        
        
        
        And, in the simple case
        
        string s1 = "ab";
        string s2 = "cde"
        s1 = s2; (3)
        s1 = string'(s2); (4)
        (3) is legal, but, would (4) produce a run time error?
        
        (3) and (4) are both legal. The previous size of s1 is
irrelevant.
        
        
        
        And, in a more complicated case,
        
        typedef string source_t1[2];
        typedef string dest_t1[];
        
        source_t1 a1;
        dest_t1 b1 = new[2];
        
        a1[0] = "ab";
        a1[1] = "c";
        b1[0] = "defg";
        b1[1] = "hijk";
        
        b1 = dest_t1'(a1); (1)
        b1 = a1; (2)
        (1) is illegal, as the lhs bit length is different than rhs bit
length
        
        I think this case, a nested dynamic type, is undefined in the
LRM. I would be OK with making this type of cast illegal. But I would
also be OK with
        
        b1[0] = abc ;.
        
        
        (2) is legal, since each element is equivalent and the array
lengths are equal
        
        I agree.
        
        
        
        
        Surrendra

        
        
        **********************************************
        Surrendra A. Dudani
        Synopsys, Inc.
        377 Simarano Drive, Suite 300
        Marlboro, MA 01752
        
        Tel: 508-263-8072
        Fax: 508-263-8123
        email: Surrendra.Dudani@synopsys.com
        **********************************************
Received on Wed Nov 17 13:44:17 2004