Re: [sv-bc] E-mail Vote: Closes 12am PST Nov 17

Thank you, I understand the issue much better now.

C++ found it useful to offer several flavors of casting to discriminate
between safe/unsafe and more/less useful unsafe casts.

Bit stream treatment of dynamically sized objects seems pointless.
It certainly violates one stated property of the bit stream casts:
that they are invertible.

 From the coziness of the synthesizable subset, I wish the simulators luck
with this one.

Greg

Mark Hartoog wrote:
>>Unless you
>>think that casting an object to TypeA as another TypeA should alter
>>some bits? Could you elaborate on your doubts about assignment
>>compatible vs equivalence here?
>
>
> The description of array assignment in section 4.7 describes it as taking
> place element by element.
>
> The description of bit-stream casting in section 3.16 says that all the
> bits of the source are put into a single bit stream, and then this bit
> stream is converted to the target type. It then says:
>
> "If the destination type, dest_t, includes unbounded dynamically-sized
> types, the conversion process is greedy: compute the size of the source_t,
> subtract the size of the fixed-size data items in the destination, and then
> adjust the size of the first dynamically sized item in the destination to
> the remaining size; any remaining dynamically-sized items are left empty."
>
> I think this means all of data from all the 'a' fields of different elements
> of source array will end up in the 'a' field of the first element of the target.
> This is completely different than an element by element assignment, in addition
> to not being very useful.
>
>
>
>>-----Original Message-----
>>From: Greg Jaxon [mailto:Jaxon@synopsys.COM]
>>Sent: Tuesday, November 16, 2004 3:54 PM
>>To: Mark Hartoog
>>Cc: Maidment, Matthew R; sv-bc@eda.org
>>Subject: Re: [sv-bc] E-mail Vote: Closes 12am PST Nov 17
>>
>>
>>Mark Hartoog wrote:
>>
>>
>>>291 ___Yes _x_No
>>>http://www.eda.org/svdb/bug_view_page.php?bug_id=0000291
>>>I have no problem with the clarification of the assignment order,
>>>but on the change from assignment compatible elements to type equivalent
>>>elements, I am concerned that we have completely changed direction on the
>>>issues of array assignment and casting several times over the last
>>>year. The argument is we need to make these changes to be consistent
>>>with bit stream casting, but I am not convinced that the current
>>>description of bit stream casting makes sense, particularly
>>>concerning dynamic types. Consider this case:
>>>
>>>typedef struct ( byte a[]; } ST;
>>>typedef ST TypeA[0:1];
>>>TypeA a;
>>>TypeA b;
>>>
>>>I think
>>>
>>> a = b;
>>>
>>>and
>>> a = TypeA'(b);
>>>
>>>do completely different things both with and without this change.
>>
>>Perhaps their internal workings differ, but the net effect is that
>>every bit of b winds up in an equivalent position in a. Unless you
>>think that casting an object to TypeA as another TypeA should alter
>>some bits? Could you elaborate on your doubts about assignment
>>compatible vs equivalence here?
>>
>>Greg
>>
>>
>>
>
>
>
Received on Tue Nov 16 16:51:35 2004