|
From: Cary R. <cy...@ya...> - 2015-01-08 20:50:34
|
FYI Steve does not allow us to check in code that has either shift/reduce or reduce/reduce errors.
The standard way to work around this is to flatten things into a single rule that can then match the text correctly (no shift or reduce just more processing), but that is not always possible. I looked at your example very quickly and it does look complicated. I normally have to spend some time thinking about how bison is working/parsing the text before I figure it out what needs to be done or realize it's not actually possible. I can look at this later when I have some time if you would like.
There are a few things in Verilog that require more than default bison supports (e.g. see br493).
Cary
On Thursday, January 8, 2015 12:15 PM, Pete Johnson <pe...@be...> wrote:
Martin,
Shift reduce conflicts are not all that uncommon. You get one with the standard if statement. Think of the following…
if (test) if (another_test) statement; else statement;
When parsing the else statement do you shift the else into the inner if expression or do you reduce the if and let the else go with the outer if. Shift reduce conflicts are resolved by shifting so the else goes with the inner if - regardless of indenting.
Reduce/reduce conflicts are a problem though. You should never have any of those.
In your case will you get the correct behavior if the conflict resolves as a shift?
Here is a link to the bison page on the subject along with how to use a pragma to suppress the warning.
http://www.gnu.org/software/bison/manual/html_node/Shift_002fReduce.html
-Pete
On Jan 8, 2015, at 11:33 AM, Martin Whitaker <mai...@ma...> wrote:
I'm trying to add support for SystemVerilog modports to the iverilog parser.
The relevant snippet from parse.y looks like this:
modport_item
: IDENTIFIER
{ pform_start_modport_item(@1, $1); }
'(' modport_ports_list ')'
{ pform_end_modport_item(@1); }
;
modport_ports_list
: modport_ports_declaration
| modport_ports_list ',' modport_ports_declaration
;
modport_ports_declaration
: attribute_list_opt port_direction modport_simple_port_list
{ pform_add_modport_ports(@2, $1, $2, $3); }
| attribute_list_opt import_export modport_tf_port_list
{ ... }
| attribute_list_opt K_clocking IDENTIFIER
{ ... }
;
modport_simple_port_list
: IDENTIFIER
{ $$ = make_port_list($1, 0); }
| '.' IDENTIFIER '(' expression ')'
{ $$ = make_port_list($2, $4); }
| modport_simple_port_list ',' IDENTIFIER
{ $$ = make_port_list($1, $3, 0); }
| modport_simple_port_list ',' '.' IDENTIFIER '(' expression ')'
{ $$ = make_port_list($1, $4, $6); }
;
which is giving me a shift/reduce conflict. The problem is the parser can't
distinguish between a ',' that separates items in a modport_simple_port_list
and one that separates items in a modport_ports_list.
I can't find a way to avoid the conflict with a single level of lookahead. Can
anyone else?
------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel
------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
Iverilog-devel mailing list
Ive...@li...
https://lists.sourceforge.net/lists/listinfo/iverilog-devel
|