RE: [sv-bc] part selects on arbitrary expressions

no problem 

> -----Original Message-----
> From: Gordon Vreugdenhil [mailto:gordonv@model.com] 
> Sent: Monday, November 05, 2007 11:58 PM
> To: Bresticker, Shalom
> Cc: sv-bc@server.eda.org
> Subject: Re: [sv-bc] part selects on arbitrary expressions
> 
> I'd much rather keep this down to a simpler change, 
> especially coming in this late in the game.  I think I can 
> accept the "select of a concat" as a non-lval expression, but 
> not much more at this point.
> 
> Gord.
> 
> 
> Bresticker, Shalom wrote:
> > Should selects of concatenations be allowed on the 
> left-hand side of 
> > assignments or only on the right-hand side?
> > 
> > Thanks,
> > Shalom
> > 
> >> -----Original Message-----
> >> From: owner-sv-bc@server.eda.org
> >> [mailto:owner-sv-bc@server.eda.org] On Behalf Of Brad Pierce
> >> Sent: Monday, November 05, 2007 7:34 AM
> >> To: sv-bc@server.eda.org
> >> Subject: RE: [sv-bc] part selects on arbitrary expressions
> >>
> >> Shalom,
> >>
> >> Yes, I'd be OK with selects of concatenations as a first step for 
> >> 2008.
> >> I can imagine someone considering it weird if (a)[0] and a[0] had 
> >> different results and not so weird if {a}[0] and a[0] did so.
> >>
> >> And it's no less convenient to write {a+b}[0] than (a+b)[0].
> >>
> >> BTW would {a+b}[0] return the right-most bit?  If we add 
> support for 
> >> selects of concatenations, we should also make sure that 
> the result 
> >> of
> >> type() applied to a concatenation is clearly defined.
> >>
> >> A related nice enhancement would be to allow the concatenation of 
> >> unpacked operands (of bit-stream types), returning a simple bit 
> >> vector.
> >>
> >> -- Brad
> >>
> >> -----Original Message-----
> >> From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com]
> >> Sent: Sunday, November 04, 2007 7:20 PM
> >> To: Brad Pierce; sv-bc@eda.org
> >> Subject: RE: [sv-bc] part selects on arbitrary expressions
> >>
> >> I have been thinking about this for a long time. I believe 
> that the 
> >> simplest thing to do and the way that has the best chance of being 
> >> passed within the short time that we have is to define selects on 
> >> concatenations. There is no ambiguity in that case. It has some 
> >> limitations, you only have vectors, but I believe it would 
> still add 
> >> a lot of usefulness.
> >>
> >> Shalom
> >>
> >>> -----Original Message-----
> >>> From: owner-sv-bc@server.eda.org
> >>> [mailto:owner-sv-bc@server.eda.org] On Behalf Of Brad Pierce
> >>> Sent: Sunday, November 04, 2007 10:50 PM
> >>> To: sv-bc@server.eda.org
> >>> Subject: Re: [sv-bc] part selects on arbitrary expressions
> >>>
> >>> Following up to http://www.eda-stds.org/sv-bc/hm/5506.html
> >> , I, too,
> >>> would like to see this enhancement (selects of arbitrary
> >> primaries) in
> >>
> >>> SV-2008.
> >>>  
> >>> In SV-2005, for any expression 'expr',  one can already declare
> >>>  
> >>>    var type(expr) temp;
> >>>  
> >>> and then write
> >>>  
> >>>    temp = expr;
> >>>    ... temp[5] ...
> >>>  
> >>> But one ought to be able to simply write
> >>>  
> >>>    ... (expr)[5] ...
> >>>  
> >>> More generally, for any primary 'p', one ought to be able to write
> >>>  
> >>>    ... p[5] ...
> >>>  
> >>> Consider the defintion of static cast --
> >>>  
> >>>    "If the expression is assignment compatible with the
> >> casting type,
> >>> then the cast shall return the value that a variable of 
> the casting 
> >>> type would hold after being assigned the expression."
> >>>  
> >>> We could come up with a similar rule that generalizes selects.
> >>>  
> >>> I don't think it's a strong argument against this
> >> enhancement to say
> >>> that the type() operator is not well enough defined, as noted in
> >>>
> >>>          http://www.eda-stds.org/sv-bc/hm/7082.html
> >>>
> >>> To me that is just an argument for clarifying the 
> definition of the
> >>> type() operator.
> >>>  
> >>> -- Brad
> >>>
> >>> --
> >>> 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.
> >>
> > 
> ---------------------------------------------------------------------
> > 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.
> > 
> 
> --
> --------------------------------------------------------------------
> Gordon Vreugdenhil                                503-685-0808
> Model Technology (Mentor Graphics)                gordonv@model.com
> 
---------------------------------------------------------------------
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.