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


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