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