RE: [sv-ec] Re: [sv-bc] Musings on array assignment compatibility

foreach'() is Arturo's.

-- Brad
________________________________
From: owner-sv-ec@eda.org [owner-sv-ec@eda.org] On Behalf Of Greg Jaxon [Greg.Jaxon@synopsys.COM]
Sent: Wednesday, June 03, 2009 10:50 AM
To: Rich, Dave
Cc: sv-bc@eda.org; sv-ec@eda.org
Subject: Re: [sv-ec] Re: [sv-bc] Musings on array assignment compatibility

Dave

Would you consider '(array) rather than {array} ?
This is a variation on Brad's foreach'() proposal.
foreach'() does not share [=]'s lack of generality as I claimed earlier.

Concat has a lot overloaded upon it already.
I'm not sure whether or not  UAC is consistent with some of the aboriginal SV syntax, but
going farther back, we find lots of non-standard concat and repeat_concat behavior in antique implementations.
I doubt there's room for any new semantics there.

I'm in favor of element wise coercions on assignment with no special syntax.  I think 2611's original idea
is good enough.  The very minor incompatibility for dynamic array casting is (in my mind) a bug fix, since
the coercion will preserve arithmetic meaning much better than an unsafe bitstream cast.

JMHO,
Greg

Rich, Dave wrote:
Greg,

Regardless of which proposal modes forward, both the BC/EC committees have agreed in principal that a simple array assignment requires elements with equivalent types. So any proposal would clarify this rule, removing existing contradictions.

The UAC proposal is just a clarification that element unraveling of embedded arrays assigns each element using assignment compatibility rules. Assignment patterns do not unravel elements of arrays. There is no new functionality or new duplication here. It’s just an informative note that for single dimensional arrays, you can get the assignment compatibility people are looking for when copying arrays simply by enclosing the array in braces.


________________________________
From: owner-sv-ec@server.eda.org<mailto:owner-sv-ec@server.eda.org> [mailto:owner-sv-ec@server.eda.org] On Behalf Of Greg Jaxon
Sent: Tuesday, June 02, 2009 10:16 PM
To: sv-bc@eda.org<mailto:sv-bc@eda.org>
Cc: sv-ec@eda.org<mailto:sv-ec@eda.org>
Subject: [sv-ec] Re: [sv-bc] Musings on array assignment compatibility

The Unpacked Array Concatenation (UAC) form requires an extensive proposal whose details we have not seen,
and which probably duplicate features already provided by assignment patterns to unpacked arrays. Please note
that in an assignment pattern the elements need only be assignment compatible, so the compelling case of
unpacked array initialization is already covered adequately.

As I understood the 2611 proposal, all unpacked structure needed to be conformable (same rank, same unpacked dimension lengths).
Only packed elements could be truncated or extended.

As much as I like the [=] [<=]  notation for elementwise assignment, it does not cover function actual or assignment pattern
activities, so it is no substitute for the 2611 proposal.   Likewise for foreach'().

The standard already encourages issuing a warning whenever an assignment silently causes a truncation or extension.
Surely a more strident warning or a standard required warning could be used to avoid users being blindsided by this extension.

Greg

Rich, Dave wrote:

If the arrays do not have matching bounds and increments, and the

element types are not equivalent, I question the value of having a piece

of syntax that lets you blindly make an assignment from one array to

another.



I feel the UAC form covers the majority of cases, and the rest (like the

foreach'() cast) can be left for an enhancement in a future revision.





-----Original Message-----

From: Jonathan Bromley

Sent: Tuesday, June 02, 2009 9:59 AM

To: Rich, Dave

Cc: sv-bc@server.eda.org<mailto:sv-bc@server.eda.org>; sv-ec@server.eda.org<mailto:sv-ec@server.eda.org>

Subject: RE: [sv-bc] Musings on array assignment compatibility



Dave Rich wrote:





BTW your examples are all packed arrays, not unpacked.



Ouch - that's embarrassing.  Thanks for pointing it out.

Of course I intended them to be unpacked.



Thanks for the other comments too.  One specific response:





int A[2][2];

byte B[2][2];



Isn't the intent clearer to write as

  foreach(A[i,j]) A[i][j] = B[i][j];

rather than

  $cast(A,B);



Definitely; but the problem is - and has always been -

that this only works because you happen to know

that all the dimensions have matching bounds and

increments.  Given



  int A[1:2][1:0];

  byte B[1:0][10:11];



things get much, much messier.  Of course it *can*

be done, thanks to the query functions, but it's

not pretty.  And I don't think there is any really

general way for a user to code such a copy operation,

except perhaps by some very creative use of macros.

--

Jonathan Bromley







--

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<http://www.mailscanner.info/>, and is
believed to be clean.

--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.

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