[sv-bc] RE: [sv-ec] 2380: a proposal requiring element equivalence

Hi, some minor editorial notes:

1. In 6.22.3, the use of "shall" in "Unpacked arrays shall be assignment compatible with certain other arrays that are not of equivalent type," seems strange, since there is no specific requirement stated here. This is more of an informative statement, so "are" seems more appropriate here.


2. The following can be confusing: "Assignment shall be done by assigning each element of the source array to the corresponding element of the target array. Correspondence between elements is determined by the left-to-right order of elements in each array. For example, if array A is declared as int A[7:0] and array B is declared as int B[1:8], the assignment A = B; will assign element B[1] to element A[7], and so on."

In the current LRM text, this text is part of a paragraph describing assignment to fixed-size arrays, where there is a requirement that the source and target have the same number of elements. Deleting the text that restricts the paragraph to fixed-size arrays makes the text more general, but it is confusing if either side is dynamic in size.


3. In the same place, the proposal does not show the following changes, which may confuse the editor: The sentence "Element correspondence is defined as leftmost to leftmost, rightmost to rightmost, irrespective of index values," is deleted, and so is the following paragraph break.


4. In the change to 11.2.2, there should be a period after "6.22.2".


5. This change to 11.2.2, if passed, also resolves Mantis 2533.

Thanks,
Shalom
 

> -----Original Message-----
> From: owner-sv-ec@server.eda.org 
> [mailto:owner-sv-ec@server.eda.org] On Behalf Of 
> jonathan.bromley@doulos.com
> Sent: Monday, June 08, 2009 5:39 PM
> To: sv-ec@server.eda.org; sv-bc@server.eda.org
> Subject: [sv-ec] 2380: a proposal requiring element equivalence
> 
> Last week's discussions were somewhat inconclusive
> but it seems clear we should preserve the 
> requirement that array elements be type-equivalent
> for the arrays to be assignment compatible. 
> I went through the relevant text as carefully 
> as I could, and rewrote the proposal to insist 
> on type equivalence; it's now attached as an 
> alternative version.  PLEASE NOTE there are 
> now TWO QUITE DIFFERENT proposals attached to
> 2380:  "v1" relaxing the rules to allow
> assignment compatible elements, "v2" affirming
> the need for type-equivalent elements.
> 
> Good features of the new (v2) proposal:
> - No problem with back-compatibility of bitstream 
>   casts; that all stays the same as 1800-2005.
> - BC's wish for stricter type checking on array
>   copy operations appears to be satisfied.
> - The loophole provided by unpacked array 
>   concatenation is still there, allowing
>   copy of 1-dimensional arrays with merely
>   assignment compatible element types:
>     arr1 =  arr2 ; // needs type-equivalent elements
>     arr1 = {arr2}; // needs assignment-compatible elements
> 
> Less good:
> - Strange asymmetry between rules for the outermost
>   (slowest-varying) dimension and all the others,
>   especially when a mix of queue/dynamic/fixed
>   dimensions is present.
> - No simple way to copy multi-dimensional arrays
>   with elements that are assignment compatible but 
>   not equivalent.
> 
> Please review.
> 
> Thanks
> -- 
> Jonathan Bromley
> 
> 
> 
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> 
> 
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.