RE: [sv-bc] Mantis 2380: array assignment compatibility

From: Bresticker, Shalom <shalom.bresticker_at_.....>
Date: Wed May 20 2009 - 05:57:26 PDT
I am in favor of requiring only assignment compatibility, and think this would be more internally consistent.

Shalom 

> -----Original Message-----
> From: owner-sv-bc@server.eda.org 
> [mailto:owner-sv-bc@server.eda.org] On Behalf Of 
> jonathan.bromley@doulos.com
> Sent: Wednesday, May 20, 2009 3:31 PM
> To: sv-bc@server.eda.org
> Subject: [sv-bc] Mantis 2380: array assignment compatibility
> 
> hi BC,
> 
> Towards the end of the ballot review, BC pushed across
> to EC a few ballot items relating to the assignment
> compatibility of unpacked arrays - Mantis 2380 covers
> them all.  Although EC didn't have time to consider it
> before the May 14 deadline, I would like to get a 
> proposal prepared ready for the recirculation.
> Although this is now an EC matter, I'd be grateful for
> any comments you may have on the following suggestions.
> 
> The critical question is whether it is OK (as I and
> at least some other members of EC believe) to relax
> the existing rules for unpacked array assignment
> compatibility so that the elements of the source
> and target arrays need only be of ASSIGNMENT COMPATIBLE
> types, rather than the current stricter requirement 
> that source and target elements be of EQUIVALENT type.
> This relaxation would automatically deal with a number
> of areas where the LRM is currently self-contradictory
> or, at least, confusing (the confusion has been 
> compounded by various changes introduced by Mantis
> items 1447 and 1702, which were passed some time ago).
> 
> Another advantage of this proposed relaxation would be
> that it removes a restriction that seems confusing and
> unnecessary to many users.  On the other hand, type 
> equivalence of elements means that some kinds of 
> unpacked array copy operation can be implemented as 
> a simple memory block copy; the proposed relaxation 
> would require implementations to do an element-by-
> element copy.
> 
> Thanks in advance for your thoughts on this.
> -- 
> Jonathan Bromley
> Consultant
> 
> Doulos - Developing Design Know-how
> VHDL * Verilog * SystemVerilog * SystemC * PSL * 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                        http://www.doulos.com
> 
> --------------------------------------------------------------
> ------------------
> Doulos Ltd is registered in England and Wales with company no. 3723454
> Its registered office is 4 Brackley Close, Bournemouth International 
> Airport,
>         Christchurch, BH23 6SE, UK. 
> 
> This message may contain personal views which are not the views of
> Doulos, unless specifically stated.
> 
> 
> -- 
> 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.
Received on Wed May 20 06:09:56 2009

This archive was generated by hypermail 2.1.8 : Wed May 20 2009 - 06:10:37 PDT