Gord, > Jonathan, the big issue here is efficiency. If you have > equivalent types, many operations can be done via > direct memory operations rather than a true element wise > operation which may require representation conversions. > This is one of those implementor driven restrictions that > conceptually could easily be relaxed but would cause > implementation issues if one did. OK, that makes sense, thanks. Let's go with "equivalent". ~~~~~~~~~~~~~~~~ Brad, > assigning a slice is not exactly an element-by-element assignment, > if that is taken to mean a series of assignments. For example, > int A[4]; > ... > A[2:3] = A[1:2]; > is not the same as > A[2] = A[1]; > A[3] = A[2]; Indeed so, but of course you can fix that for slices by juggling the copy direction. However, you need to be quite careful in cases like this (assuming we have unpacked array concatenation): A = {A[3], A[1:2], A[0]}; Neither forward nor backward element-by-element copying will work correctly here; I suspect there's no alternative to creating an intermediate temporary copy. I'm sure we can trust the implementors to get this right :-) -- 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 Wed Nov 28 08:52:26 2007
This archive was generated by hypermail 2.1.8 : Wed Nov 28 2007 - 08:53:02 PST