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

I believe there is a backwards incompatibility here for certain uses of
casting.
> If the expression is not assignment compatible with the casting type,
> then [...] if the casting type is a bit-stream type, the behavior
> shall be as described in 6.24.3.
Many unpacked arrays are bit-stream types; Section 6.24.3 specifies the
(unsafe) sort of cast where the
bits stay the same and only the type changes; it also specifies 4->2
state casting of the bits.
By enlarging the definition of assignment compatibility,  the above
clause is robbed of many cases that
it previously had covered.  I have not yet tried to construct a specific
counterexample, and there might
be no "trivial" counterexample.  But these definitions allow a large
variety of combinations, so I'm
not yet convinced that no legal bit-stream casts will become coercive
casts under your proposal.

Has a proof of this been presented?

Greg Jaxon

jonathan.bromley@doulos.com wrote:
> 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.
>
>   


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