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

From: Surrendra Dudani <Surrendra.Dudani@synopsys.com>
Date: Wed Nov 17 2004 - 08:25:43 PST

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 08:24:52 2004