| Add Proposal | Add Analysis | Edit Class, Environment, or Release |
| Number | 474
|
| Category | enhancement
|
| Synopsis | First class part selection operator
|
| State | open
|
| Class | enhancement
|
| Arrival-Date | Sep 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