ISSUE 474

Add Proposal  Add Analysis  Edit Class, Environment, or Release
Number 474
Category enhancement
Synopsis First class part selection operator
State open
Class enhancement
Arrival-DateSep 16 2003
Originator Adam Krolnik
Release 2001b
Environment
Description
Current the part selection operator can only be applied to
reg/net/variable names. It is not a first class operator.

As a first class operator, it could be used on an anonymous
expression, something like:

{a & b | c}[4:2] // Return bits 4:2 of the result.

This solves some lint warning problems, where one
intends to only use some of the bits. Lint warns
when bits are not used (possibly an error.) A construct
like this could be used to show unambiguously that
only specific bits are desired.

Fix
Audit-Trail
From: "Jay Lawrence" <lawrence@cadence.com>
To: <krolnik@lsil.com>, <etf-bugs@boyd.com>
Cc:
Subject: RE: errata/474: First class part selection operator
Date: Tue, 16 Sep 2003 14:42:29 -0400

Adam,

Please take a look at

http://www.boyd.com/1364_btf/report/full_pr/409.html

It is an existing enhancment request that begins with a discussion of
allowing lists in bit/part selects:

a[1,3,4:10] = .....

And then evolves into a discussion of changing bit and part selects from
an operand to an operator.

Does this discussion end up with what you are requesting?

Jay


===================================
Jay Lawrence
Senior Architect
Functional Verification
Cadence Design Systems, Inc.
(978) 262-6294
lawrence@cadence.com
===================================

> -----Original Message-----
> From: krolnik@lsil.com [mailto:krolnik@lsil.com]
> Sent: Tuesday, September 16, 2003 12:44 PM
> To: etf-bugs@boyd.com
> Subject: errata/474: First class part selection operator
>
>
> Precedence: bulk
>
>
> >Number: 474
> >Category: errata
> >Originator: Adam Krolnik
> >Environment:
>
> >Description:
>
>
> Current the part selection operator can only be applied to
> reg/net/variable names. It is not a first class operator.
>
> As a first class operator, it could be used on an anonymous
> expression, something like:
>
> {a & b | c}[4:2] // Return bits 4:2 of the result.
>
> This solves some lint warning problems, where one
> intends to only use some of the bits. Lint warns
> when bits are not used (possibly an error.) A construct
> like this could be used to show unambiguously that
> only specific bits are desired.
>
>

From: Shalom.Bresticker@motorola.com
To: Jay Lawrence <lawrence@cadence.com>
Cc: etf-bugs@boyd.com
Subject: RE: errata/474: First class part selection operator
Date: Tue, 16 Sep 2003 21:57:00 +0300 (IDT)

Jay,

I agree with both of you.

I agree that it is the same as what was discussed in 409,
and I agree that it should be a separate enhancement request than
the original 409 request.

Shalom


On Tue, 16 Sep 2003, Jay Lawrence wrote:

> Adam,
>
> Please take a look at
>
> http://www.boyd.com/1364_btf/report/full_pr/409.html
>
> It is an existing enhancment request that begins with a discussion of
> allowing lists in bit/part selects:
>
> a[1,3,4:10] = .....
>
> And then evolves into a discussion of changing bit and part selects from
> an operand to an operator.
>
> Does this discussion end up with what you are requesting?
>
> Jay
>
>
> ===================================
> Jay Lawrence
> Senior Architect
> Functional Verification
> Cadence Design Systems, Inc.
> (978) 262-6294
> lawrence@cadence.com
> ===================================
>
> > -----Original Message-----
> > From: krolnik@lsil.com [mailto:krolnik@lsil.com]
> > Sent: Tuesday, September 16, 2003 12:44 PM
> > To: etf-bugs@boyd.com
> > Subject: errata/474: First class part selection operator
> >
> >
> > Precedence: bulk
> >
> >
> > >Number: 474
> > >Category: errata
> > >Originator: Adam Krolnik
> > >Environment:
> >
> > >Description:
> >
> >
> > Current the part selection operator can only be applied to
> > reg/net/variable names. It is not a first class operator.
> >
> > As a first class operator, it could be used on an anonymous
> > expression, something like:
> >
> > {a & b | c}[4:2] // Return bits 4:2 of the result.
> >
> > This solves some lint warning problems, where one
> > intends to only use some of the bits. Lint warns
> > when bits are not used (possibly an error.) A construct
> > like this could be used to show unambiguously that
> > only specific bits are desired.
> >
> >
>

--
Shalom Bresticker Shalom.Bresticker@motorola.com
Design & Reuse Methodology Tel: +972 9 9522268
Motorola Semiconductor Israel, Ltd. Fax: +972 9 9522890
POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 441478


From: Steven Sharp <sharp@cadence.com>
To: etf-bugs@boyd.com, Shalom.Bresticker@motorola.com
Cc:
Subject: RE: errata/474: First class part selection operator
Date: Tue, 16 Sep 2003 19:13:34 -0400 (EDT)

Perhaps we should append the relevant parts of that other request here.

Steven Sharp
sharp@cadence.com


From: Shalom.Bresticker@motorola.com
To: etf-bugs@boyd.com
Cc:
Subject: Re: errata/474: First class part selection operator
Date: Thu, 18 Sep 2003 10:57:34 +0300 (IDT)

This is to attach the discussion from 409.

Date: Fri, 1 Aug 2003 08:15:38 -0400
From: Jay Lawrence <lawrence@cadence.com>
To: Shalom Bresticker <Shalom.Bresticker@motorola.com>, etf-bugs@boyd.com
Subject: RE: enhancement/409: lists in part-selects

I think this is an interesting enhancement that makes currently
expressible things more succinct and clear. As long as the user
community does not confuse succinctness with performance this is OK.

This enhancement is closely related to another concept we've been
discussing internally here at Cadence related to bit-selects,
part-selects, and data types.

Bit-selects and part-selects are currently defined as operands, not as
an operator. Most other languages treat subscripting as a general
operator. This allows things like subscripting to participated in
precendence relationships and arbitrary expressions. Once the language
has things like structs you get (for some struct s) expressions like:

s.x[2]

Now you need to define structure references as an operand as well or
define precedence of '.' and '[]'.

One advantage of treating subscripting as an operator would be
simplifying the LRM signficantly. Currently anywhere operands are
discussed there is are special rules about bit-selects and
part-selects.
If we just made them operators and defined what objects they were
allowed to operate on all this special purpose text goes away.

It appears your enhancments request here would fit into this concept
nicely. The [] operator would be defined to be able to contain a list
of either integers or ranges.

There are some difficult cases like:

reg [10:0] r1;
reg [20:10] r2;
reg r;

r = (r1 & r2)[3];

What is the range of the expression (r1 & r2)? Is [3] a legal subscript
in this range?

Either by defining such a range, or by disallowing subscripting on
expressions with a self-determined width, but no defined range these
could be handled.

As someone who has invested a huge amount of time in clarifying the LRM,
I'd love to hear your opinion on whether this change from operand to
operator would significantly simplify the LRM.


Date: Sun, 03 Aug 2003 12:19:52 +0300
From: Shalom Bresticker <Shalom.Bresticker@motorola.com>

That's a very interesting and elegant idea.

I actually had to think about how indexing is defined in the Verilog language
when I was looking at 3.9.1, bullet 2, which seems to relate to indexing as an
operator, since the title of 3.9.1 is "Operators and real numbers".

I don't think it was deliberate there, just not very precise wording and
organization, but it got me to thinking about it.

I understand what you wrote and I think it is worth further work.
I am not sure it would simplify the LRM, though.

You wrote that "Most other languages treat subscripting as a general
operator. " Could you give a couple of references?
My first mental association when I read that was the APL language,
but I am not familiar with how languages like C and PERL relate to it.

I like the idea of being able to write (r1 & r2)[3].
One other feature which would be occasionally useful is subscripting of
constants.


Date: Mon, 4 Aug 2003 10:11:57 -0700
From: Michael McNamara <mac@verisity.com>

In Appendix A, section 7.3 of tha ANSI C standard, C defines [] as one
of its postfix operators (along with exp ++, exp --, exp -> id, exp
. id, and exp () ).

Hence in C you can do things like:

char a = "hello world"[6];

or

a = m(6)[4]; // assuming m returns an array (or pointer);

C++ goes further and allows you to overload the subscript operator []
by saying:

class X {
X operator []() {
//
}
}

Java pulled back from that degree by removing the overload facility.

Perl went further than C, but no overload; allowing appling this
operator to anonymous arrays and hashes:

$a = (1,2,3)[2];


Date: Sun, 17 Aug 2003 17:28:57 +0300 (IDT)
From: Shalom.Bresticker@motorola.com

Coincidentally, I just saw the following on comp.lang.verilog:

=========================================================================
Subject: syntax question
Date: Fri, 15 Aug 2003 14:37:20 -0700
From: Ron Smith <rdsmith@sedona.intel.com>
Newsgroups: comp.lang.verilog

Why does this work:

wire [1:0] foo,bar;

assign {foo,bar}=4'b1000;

at setting foo to 2'b10 and bar to 2'b00, but this gives a syntax error:

wire [1:0] foo,bar;

assign {foo,bar}=4'b0000;
assign {foo,bar}[3]=1'b1;

but this also works:

wire [3:0] foobar;

assign foobar=4'b0000;
assign foobar[3]=1'b1;

Please note that I'm not trying to argue over the finer points of style,
the above is simply a trivial and overly simplistic example of something
I tried that I thought "should" work, but of course it didn't.


Date: Wed, 20 Aug 2003 11:38:55 -0700
From: Michael McNamara <mac@verisity.com>

In a language like perl assign {foo.bar}[3] = 1'b1; would work; and I
believe it is a useful RFE for 1364 verilog. Again, one would
discourage folks from typing the above directly; but it may be very
useful to do:

`define CPU_REG {mode,exception_mask,interrupt_mask,cpu_id}


...

if ( `CPU_REG[5:0] == 6'b0 ) begin
// we are the boot cpu; load the OS
...
end

which would expand to the same thing.


From: Steven Sharp <sharp@cadence.com>
To: etf-bugs@boyd.com
Cc:
Subject: Re: errata/474: First class part selection operator
Date: Thu, 18 Sep 2003 12:15:21 -0400 (EDT)

I am forwarding a copy of part of the local discussion that Jay refers to.
It might be relevant to this enhancement request.


>On page 42 of the 2001 LRM the operator precedence table does not
>include:
>
> ".", "()", "[]"
>
>Should we file an errata on this? In the stuff on dereference I'm doing
>for handles we are going to need to introduce unary * and -> and the
>precendence relative to the above will be important.

In the existing LRM, these are not considered to be operators. The "."
is not described as an operator; instead, it is considered part of a
hierarchical name, a special identifier. The LRM even disallows spaces
around the "." in the name. I have suggested that this restriction be
removed and the "." be treated more like an operator.

The "[]" is not described as an operator; instead, bit and part selects
are operands of expressions involving real operators.

I assume you are referring to "()" meaning a function call. Again, this
is not regarded as an operator.

They can get away with this because there are so many restrictions on
how these operators can be applied. For example, a function name can
only be used with "()", and "()" can only be used with a function name.
So the name and the argument list can be regarded as part of the same
operand, not as an operator applied to an operand. Note that in Verilog,
the "()" can be left off of a system function call that has no arguments
(Verilog HDL functions are required to have arguments), so it really
isn't an operator meaning function call anyway.

Similarly, an array can only be referenced with "[]", and (except for
bit and part selects) "[]" can only be used with an array. The same
thing applies to "." and a scope.

Also, you can't parenthesize all of the "operands" of these "operators",
so they aren't really separable operands being acted on by operators in
expressions. For example, you can't say (array)[i], or (name1).(name2)
or (func)(i).

I know that there was a proposal to add some entries to the operator
precedence table. For example, the "{}" and "{{}}" (concatenation and
multi- concatenation) operators were added. It wasn't clear what precedence
to use for them, since they are self-parenthesizing and don't rely on
precedence. This made it meaningless to add them to the table. I think
the event-or got left out after some discussion, because it wasn't being
referred to as an operator in other sections, and putting the "," version of
it into the table would have been confused with other uses of commas. I
think they may have added something else too. Overall I think it would
have been better left alone.

Steven Sharp
sharp@cadence.com

------------- End Forwarded Message -------------


Steven Sharp
sharp@cadence.com


From: Shalom.Bresticker@motorola.com
To: Steven Sharp <sharp@cadence.com>
Cc: etf-bugs@boyd.com
Subject: Re: errata/474: First class part selection operator
Date: Thu, 18 Sep 2003 21:04:07 +0300 (IDT)

Thanks, Steven.

Just one comment:

> In the existing LRM, these are not considered to be operators. The "."
> is not described as an operator; instead, it is considered part of a
> hierarchical name, a special identifier. The LRM even disallows spaces
> around the "." in the name. I have suggested that this restriction be
> removed and the "." be treated more like an operator.

While 2001 does disallow spaces around "." (though 1995 does not) and it
is not considered an operator, allowing spaces, like both you and I
propose (there is already an issue filed on this, which I am handling),
does not mean it is treated like an operator, just like the other cases
you mention, such as [], do allow spaces, but are not currently considered
operators.

We can turn . into an operator, but that is a separate issue than the
spaces, though related.

--
Shalom Bresticker Shalom.Bresticker@motorola.com
Design & Reuse Methodology Tel: +972 9 9522268
Motorola Semiconductor Israel, Ltd. Fax: +972 9 9522890
POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 441478


From: Steven Sharp <sharp@cadence.com>
To: sharp@cadence.com, Shalom.Bresticker@motorola.com
Cc: etf-bugs@boyd.com
Subject: Re: errata/474: First class part selection operator
Date: Thu, 18 Sep 2003 14:20:30 -0400 (EDT)

Agreed. I hope I didn't imply that the inability to have spaces around
"." was the only way it fails to be an operator.

In current Verilog, there is no reason to want to treat "." as an
operator. There are no expressions that can produce a scope as a
result, so there is no point in allowing expressions on either side
of the "." anyway. This might change if "." starts getting used as
a struct member select also, and if there are any expressions that
can produce a struct as a result, and we want to allow applying "."
to such expressions.

Steven Sharp
sharp@cadence.com


From: Steven Sharp <sharp@cadence.com>
To: etf-bugs@boyd.com
Cc:
Subject: Re: errata/474: First class part selection operator
Date: Thu, 18 Sep 2003 19:24:01 -0400 (EDT)

Note that currently, a bit or part select is applied only to an object.
It means that you want to reference certain bits of that object, using
the bit numbering that was specified on the declaration of the object.
While it could be viewed as an "extraction" operation performed on a
value, you can also see it as an odd sort of "name" for part of an object.
So you don't necessarily have to view the current version as a "second
class operator". It just isn't an operator.

If you do want to view it as an operator and therefore generalize it,
there are some issues that have to be resolved. When applied to an
object, there is a specific range on the object declaration which defines
what the bit numbers mean. With a general expression, there is no such
declaration, and you have to define something. The obvious choice is to
treat it as if it had a range of [width-1:0] whenever it is applied to
something other than an object.

But when exactly is that and how do we specify it? Presumably this is
anything other than an identifier. This causes some oddities. For
example, if you declare "reg [0:31] r;", then r[0] refers to the MSB,
but (r)[0] refers to the LSB, because (r) is not an identifier. What
about a function call? The function return value was specified with an
explicit range. Should a function call use the range of its return type,
or should it be considered an expression and use the default range for an
object of that width?

Making bit and part selects operators that can act on any vector value
would also allow some strange syntax. Since the result of a bit or part
select is a vector, there would be nothing to prevent taking another bit
or part select of that result. That would allow things like r[i][j][k],
which might look like a reference to a multidimensional array, but is just
a bit-select of a bit-select of a bit-select. Or it would allow things
like r[7:0][6:0] or r[7:0][3], which look like some kind of array slicing
that isn't legal in Verilog, but are just further selects of the result
of a part select. You could even use r[i][3:0], which looks like a part
select of an array reference, but is actually a part select of a bit select,
with all but one of the selected bits out of range.

This means that if you put too many subscripts on your array reference,
your tool wouldn't give you an error message any more. This is already an
issue with allowing bit selects of array elements, since one too many
subscripts will be treated as a bit select. But this would allow an
arbitrary number of excess subscripts without any error.

I'm not opposed to this extension, but I want to be sure that everyone
understands the implications.

Steven Sharp
sharp@cadence.com

Unformatted

Hosted by Boyd Technology