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

For example, "$select(a+b,3,3)" makes it clear that a+b is a
self-determined expression, and the subscript/index 3 relates to that.
Otherwise, you get into questions such as whether a and b are
bit-extended and/or type-converted before the bit/part-select is
performed.

 

Shalom

 

________________________________

From: Feldman, Yulik 
Sent: Tuesday, March 06, 2007 3:20 PM
To: Bresticker, Shalom; 'sv-bc@server.eda.org'
Subject: RE: [sv-bc] part selects on arbitrary expressions

 

Hi Shalom,

 

I agree with everything you have said here, but I didn't understand what
led you to conclude that adding a system function is better than not
adding it. To me, "(a+b)[3]" is simpler to write and to read than
"$select(a+b)[3]" (or whatever the syntax), and I don't see any
substantial problem with allowing the "(a+b)[3]" (as well as "(a)[3]"),
as I argued in the previous posts. Since it is a new construct, the
semantics of "(a+b)[3]" may be defined in any appropriate way, including
the one that would match the supposed semantics of the system function.
However, syntactically, "(a+b)[3]" will be simpler to write and read,
and this is why I think it is better than the system function.

 

--Yulik.

 

________________________________

From: Bresticker, Shalom 
Sent: Tuesday, March 06, 2007 2:46 PM
To: Feldman, Yulik; 'sv-bc@server.eda.org'
Subject: RE: [sv-bc] part selects on arbitrary expressions

 

Hi, Yulik.

 

I don't agree. The parentheses turn the identifier inside into an
expression.

[Yulik] I'm not sure I follow you. In my eyes, an identifier placed in a
syntactical context where an expression is expected is an expression,
even if it not surrounded by parenthesis.

[SB] "a" is an identifier. As such, it can be a primary or an
expression. Today, only an identifier can be followed by a bit-select,
not a general primary or expression. When you put parentheses around the
identifier, it is now an expression and a primary, but no longer an
identifier, and therefore cannot be followed by a bit-select.

 

 So a[2] is legal, whereas today a[2] is not. 

[Yulik] Apparently, you forgot to put the parenthesis in one of these,
so I'm not sure what exactly you meant.

[SB] Apparently I meant that a[2] is legal, whereas (a)[2] is not legal
today.

 

(a) is not the same as a, it is an expression whose value and, to a
certain degree, type are the same as those of a.

[Yulik] What exactly the differences are and where it is defined in the
LRM? I understand that sometimes the syntax requires the presence of
parenthesis to avoid ambiguities, but I see that as a purely syntactical
issue; not semantic. To be more exact, I expect both the value and the
type of the "parenthesis expression" to be exactly the same as those of
its "operand" (not "to a certain degree"). If you show an example where
this is not the case, I would agree that the parenthesis have a special
semantic meaning.

[SB] Maybe it does have exactly the same type. But that very syntactic
difference is today what prevents directly taking bit-selects from it.
The difference is again that the case where the parentheses enclose only
a simple identifier is a special case. In general, the parentheses can
enclose a complex expression.

 

Overall, I came to the conclusion that I liked Dmitry's suggestion best,
of adding a system function to do this.

 

Shalom

 


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