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

Shalom,

Personally I don't think the BNF should work so hard to whittle down the
syntax in an attempt to prevent semantic errors.  Eventually arbitrary
primaries, not just concatenations, will need to be selectable from,
including, for example, function_subroutine_calls that return structs.

Actually, that's an interesting example even before this proposed
change, because if function 'foo' returns an object with a method 'too',
then 

        foo().too

is already legal.  (This function_subroutine_call, like any primary that
evaluates to an object, is a legal method_call_root.)

And by the Uniform Access Principle it shouldn't matter whether 'too' is
a field of a struct or a method of an object.

-- Brad 

-----Original Message-----
From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com] 
Sent: Monday, November 05, 2007 10:19 PM
To: Brad Pierce; sv-bc@eda.org
Subject: RE: [sv-bc] part selects on arbitrary expressions

Brad,

As I wrote, I've been thinking about this for a while already.

See below: 

> In A.8.4 in primary, we could replace
> 
>    concatenation
> 
> with
> 
>    concatenation select

'select' is too general. It includes member_identifiers. I checked the
BNF, and I have to make a new non-terminal which will represent
bit_select | part_select. There is also a need for a constant version of
it, for places where a constant_primary is used. For that,
constant_range_expression already exists. Surprisingly, there is not a
non-constant version of that, which is what is needed above.

> 
> and in 11.4.12, we could extend
> 
>    "The concatenation is treated as a packed vector of bits"
> 
> to say
> 
>    ", one or more of which can be selected, assuming an [n-1:0] 
> numbering."

Yes, and an example.


> Also, in 11.4.12, what's the reason for the following text?
> 
>   "Software tools can generate a warning if the concatenation width on

> one side of an assignment is different from the expression on the 
> other side. The following examples can give warning of size mismatch"
> 
> Why would a software tool need this special permission from the LRM to

> issue a warning?  In my opinion, unless a warning is mandated, it 
> shouldn't be mentioned in the LRM.

Mantis 1233 already deletes this.

Thanks,
Shalom
---------------------------------------------------------------------
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.