RE: Shift/reduce conflict in value_range of parameter declaration

Marq,

Suppose you have "from [1:2:3:4]". Should it be parsed as [(1:2:3) : 4] or as [1 : (2:3:4)]?

I don't think the standard says, even in explanatory text. The same ambiguity can exist in other places.

On the face of it, the same problem can occur in Verilog. This must have been discussed in the past there.

I think the answer is that the parser is greedy, so that the correct parsing is [(1:2:3) : 4], but I don't think the LRM says so anywhere.

Shalom


________________________________
From: owner-verilog-ams@server.eda.org [mailto:owner-verilog-ams@server.eda.org] On Behalf Of Marq Kole
Sent: Tuesday, August 25, 2009 9:58 AM
To: Surya Pratik Saha; Verilog-AMS LRM Committee
Cc: Ishita Ghosh
Subject: RE: Shift/reduce conflict in value_range of parameter declaration

Hi Surya,

In the LRM 2.3.1 it is explicitly mentioned that the grammar in Annex A is not a production quality grammar, that is, we do not guarantee that you can build a parser on it without refactoring or restructuring. It should just describe the language grammar completely and unambiguously.

The conflict you mention only applies in an LALR(1) grammar and does not occur in a LR(k) or LR(*) grammar, for example such as used by the ANTLR parser generator. This is because the value range expression will only use a single colon, while the constant mintypmax expression will use two colons. A LR(2) grammar will resolve this without conflicts. I am completely against adapting the grammar because it does not seem to fit the tool. Also I believe that using Yacc/Bison this conflict can be resolved -- it will take some additional work, though.

An even stronger argument against changing the grammar is that your proposed change would break a lot of existing code. The following pattern is used in many models:

parameter integer type = 1 from [-1:1] exclude 0;

Cheers,
Marq

From: owner-verilog-ams@server.eda.org [mailto:owner-verilog-ams@server.eda.org] On Behalf Of Surya Pratik Saha
Sent: Monday 24 August 2009 15:19
To: Verilog-AMS LRM Committee
Cc: Ishita Ghosh
Subject: Shift/reduce conflict in value_range of parameter declaration

Hi,
value_range for parameter declaration is defined as:
value_range ::=
value_range_type ( value_range_expression : value_range_expression )
| value_range_type ( value_range_expression : value_range_expression ]
| value_range_type [ value_range_expression : value_range_expression )
| value_range_type [ value_range_expression : value_range_expression ]
| value_range_type '{ string { , string } }
| exclude constant_expression
value_range_type :: = from | exclude
value_range_expression ::= constant_expression | -inf | inf

Now a constant_expression rule may contain
constant_expression ::=
constant_primary
[...]
constant_primary ::=
[...]
| ( constant_mintypmax_expression )
[...]
constant_mintypmax_expression ::=
constant_expression
| constant_expression : constant_expression : constant_expression

So after 'exclude' if we get first '(' and then ':', a rule can be reduced to both 'value_range_expression' or 'constant_mintypmax_expression'. So it is conflicting. I think LRM needs a fix by providing mandatory () for the following rule, like:

| exclude ( constant_expression )

to resolve the conflict. Please let me know. I can file mantis for future LRM enhancement.


--

Regards

Surya

--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.

--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, 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.