RE: [sv-ec] Array assignment compatibility

From: Jonathan Bromley <jonathan.bromley_at_.....>
Date: Mon Jun 23 2008 - 14:09:41 PDT
Arturo

> 1) Array Casting:
> Consider some legacy code such as:
>    typedef int AIT[10];
>    AIT   ai;
>    byte ab[10];
>    ai = ab;
> The assignment was legal (because int and byte are assignment
> compatible), but it is now illegal.

Yes, it is exactly such situations that I find are so bizarrely
affected by the "equivalent element types" rule.  However, 
the rules introduced by Mantis 1702 for unpacked array 
concatenation would unambiguously permit

   ai = {ab};

Maybe it's right to have this as the canonical way to
cast an unpacked array to another of the same shape but
with assignment-compatible rather than equivalent elements.
If that's everyone's wish, then I could live with the 
current tighter rule about simple assignment - but it
raises a query over the 1447 relaxation whereby queues, 
dynamic arrays and fixed-size unpacked arrays can be 
copied on to one another if their elements are 
assignment-compatible.

> One would think that the easiest way to make the code compliant, would
> be to add a cast:
>    ai = AIT'(ab);
> However, the rules for unpacked array casting are unspecified. Should
> the above cast be disallowed since the number of *bits* in the two
> arrays is different. Or, should the cast operate on an element by
> element basis (as with the previous assignment compatible rule). This
> needs to be clarified in the LRM.

I believe that this is a bit-stream cast (since both ai and ab 
are of bit-stream types, by the definition in 6.24.3) and it is 
illegal because they contain different numbers of bits and the
target is fixed-size and unpacked.

I agree that we don't appear to have a definition of the cast 
operation type_name'() for unpacked arrays that are not of 
bit-stream type, but I think we could live with that issue
being shelved.

> 2) Assignments with overlapping items:
> Consider this code snippet:
>    byte  a[0:3] = '{ 0,1,2,3 }; 
>    a[1:3] = a[0:2];
> Given the text stating that assignment is done element by element, is
> the above equivalent to:
>    a[1] = a[0];
>    a[2] = a[1];
>    a[3] = a[2];
> Which would yield '{ 0, 0, 0, 0 }. 

Which would clearly be insane.  If the definition suggests that this
might occur, then the definition needs fixing.  It would be triflingly
easy to write a definition based on copying via an intermediate
variable, if need be.

> This is related to Mantis items 2240 and 2221.

Sorry, I can't see the connection with 2240?
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
Tel: +44 (0)1425 471223                   Email: jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573                           Web: http://www.doulos.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Mon Jun 23 14:10:36 2008

This archive was generated by hypermail 2.1.8 : Mon Jun 23 2008 - 14:11:09 PDT