Menu
▾
▴
iverilog-devel
|
From: Martin W. <mai...@ma...> - 2015-01-08 19:33:51
|
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?
|
|
From: Pete J. <pe...@be...> - 2015-01-08 20:15:07
|
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 <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
|
|
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
|
|
From: Martin W. <mai...@ma...> - 2015-01-09 00:03:08
|
I've already tried flattening the modport_ports_list and modport_ports_declaration rules into a single rule. This doesn't fix the problem. Maybe I'm being dense, but I can't see a way to flatten the nested lists into a single rule. The only way I can think of to fix this is to build my own mini state machine and parser within the modport_ports_list rule. Cary R. wrote: > 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 > > > > > > > ------------------------------------------------------------------------------ > 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 > |
|
From: Martin W. <mai...@ma...> - 2015-01-08 23:55:37
|
Thanks for the reply Pete. The problem here is that ',' may either be a separator or terminator for the inner list, and you only know which by looking at the next syntax element. So, unlike the dangling else case, you can't always resolve the conflict in a fixed way. Pete Johnson 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 <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 > |
|
From: Evan L. <sa2...@cy...> - 2015-01-09 00:27:14
|
With no knowledge whatever of SV, I imagine the problem is that a
modport_ports_list might look like this:
in a, b, c, out d, e, f; // with a ';'?
and it's not immediately obvious to the parser if 'out' is a
port_direction, or an IDENTIFIER - is that right?
If so, you've got 2 options:
1 - find out whether 'out' is followed by a comma, which is presumably
why you mention lookahead. At first sight, I'd be inclined to handle
this by instead re-factoring a port list as something like this:
port_list
: first_port
| port_list ',' IDENTIFIER
first_port : port_direction IDENTIFIER ;
2 - add a terminal for PORT_IDENTIFIER, which is identical to
IDENTIFIER, but doesn't allow the presumably-reserved 'in', 'out', etc.
This will just work anyway if you've got your ordering correct in the
lex file - ie. you match on 'in'/'out'/etc before matching identifiers.
Having said that, I have a very vague recollection that lexing in Icarus
is table-based in some way, so you may not be able to do this. If so,
you could have a regex for PORT_IDENTIFIER which excludes the
directions. Or something like that... :)
BTW, I agree that you should never allow *any* conflicts in your grammars.
-Evan
On 08/01/2015 19:33, Martin Whitaker 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
>
|
|
From: Jonathan D. <jb_...@ya...> - 2015-01-09 02:30:07
|
Sv keywords are never identifiers unless escaped. Sent from Yahoo Mail on Android |
|
From: Evan L. <sa2...@cy...> - 2015-01-09 11:06:23
|
On 09/01/2015 02:26, Jonathan David wrote: > Sv keywords are never identifiers unless escaped. Yes, but... >> in a, b, c, out d, e, f; // with a ';'? (actually 'input a, b, c, output d, e, f') how does the parser know? It's normally trivial, but that doesn't seem to be the case here. -Evan |
|
From: Pete J. <pe...@be...> - 2015-01-09 02:15:53
|
Evan, What you suggest is not how the mod port syntax works. It uses the keywords “input” and “output”, not “in” and “out”. Here is an example from the standard interface i2; wire a, b, c, d; modport master (input a, b, output c, d); modport slave (output a, b, input c, d); endinterface Martin never told us what the non-terminal “port_direction” matches from parse.y in the icarus source it looks like it can be the keywords “input”, “output”, “inout” or “ref”. So, my guess is that the issue arises when the parser has parsed the identifier “b” and is now staring at a comma. Should it shift the comma and continue with the modport_simple_port_list non-terminal or should it reduce that and start a new mod port_ports_declaration. It is possible that Martin could use the GLR algorithm with bison rather than the default LR(1) algorithm. This would resolve the issue by essentially allowing more than one lookahead token. See http://www.gnu.org/software/bison/manual/html_node/Simple-GLR-Parsers.html <http://www.gnu.org/software/bison/manual/html_node/Simple-GLR-Parsers.html> for details on this. Otherwise you would need to have some semantic tie-in to the lexor. You would basically clue it in to the fact that you are parsing a modport and if it sees a comma followed by input, output, inout, or ref to have it conveniently return a new type of token which is not a comma, but something which explicitly indicates to the parser that the modport_simple_port_list is ending and needs to be reduced. -Pete |
|
From: <ni...@ly...> - 2015-01-09 08:19:49
|
Pete Johnson <pe...@be...> writes: > What you suggest is not how the mod port syntax works. It uses the > keywords “input” and “output”, not “in” and “out”. Here is an example > from the standard > > interface i2; > wire a, b, c, d; > modport master (input a, b, output c, d); > > modport slave (output a, b, input c, d); > > endinterface Thanks for the example. That makes it a lot easier to follow the discussion for those of us not familiar with system verilog. One question: Is the grouping of a,b and c,d essential, or is "(input a, b, output c, d)" just a shorthand for "(input a, input b, output c, output d)"? In the latter case, it would make sense to me to make it a single list of entries where the port_direction is optional, and then have some semantic rules (i.e., not really part of the grammar) which (i) remembers the most recent port_direction and applies it to following entries, and (ii) generates a syntax error in case the first entry is missing a port_direction. (Not sure if part (ii) is easy to express in the grammar, if it is, then that's preferable of course). Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. |
|
From: Iztok J. <izt...@gm...> - 2015-01-09 08:46:40
|
I do not know if this helps. Verilator already implements interfaces. I have no idea what kind of parser they use, if the source code does not help, the author might help with the discussion. Regards, Iztok Jeras On Fri, Jan 9, 2015 at 9:19 AM, Niels Möller <ni...@ly...> wrote: > Pete Johnson <pe...@be...> writes: > > > What you suggest is not how the mod port syntax works. It uses the > > keywords “input” and “output”, not “in” and “out”. Here is an example > > from the standard > > > > interface i2; > > wire a, b, c, d; > > modport master (input a, b, output c, d); > > > > modport slave (output a, b, input c, d); > > > > endinterface > > Thanks for the example. That makes it a lot easier to follow the > discussion for those of us not familiar with system verilog. > > One question: Is the grouping of a,b and c,d essential, or is "(input a, > b, output c, d)" just a shorthand for "(input a, input b, output c, > output d)"? > > In the latter case, it would make sense to me to make it a single list > of entries where the port_direction is optional, and then have some > semantic rules (i.e., not really part of the grammar) which (i) > remembers the most recent port_direction and applies it to following > entries, and (ii) generates a syntax error in case the first entry is > missing a port_direction. (Not sure if part (ii) is easy to express in > the grammar, if it is, then that's preferable of course). > > Regards, > /Niels > > -- > Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. > Internet email is subject to wholesale government surveillance. > > > ------------------------------------------------------------------------------ > 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 > |
|
From: Evan L. <sa2...@cy...> - 2015-01-09 11:06:35
|
On 09/01/2015 02:15, Pete Johnson wrote: > modport master (input a, b, output c, d); Ok - thanks for the example - my 'modports_port_list' example parse should therefore look like this: input a, b, c, output d, e, f this can always be parsed with one token of look-ahead as long as the lexer can distinguish between 'port_direction' and IDENTIFIER (it needs to do this when it reaches 'output', not ','). This begs the question of why it can't, which is what (2) in my last post was about. -Evan |
|
From: <ni...@ly...> - 2015-01-09 11:47:18
|
Evan Lavelle <sa2...@cy...> writes:
> Ok - thanks for the example - my 'modports_port_list' example parse
> should therefore look like this:
>
> input a, b, c, output d, e, f
>
> this can always be parsed with one token of look-ahead as long as the
> lexer can distinguish between 'port_direction' and IDENTIFIER (it needs
> to do this when it reaches 'output', not ','). This begs the question of
> why it can't, which is what (2) in my last post was about.
I hope I understand this correctly. I think the grammar fragment given
wants to parse
input a, b, c, output d, e, f
as
(input (a , b , c)) , (output (d , e , f))
where I use parentheses to mark sequences of tokens corresponding to a
non-terminal. Outer parentheses correspond to modport_ports_declaration,
and the inner to modport_simple_port_list. And that's why it needs to
make a decision when examining each comma.
I think the sane solution is to reorganize the grammar so that this
example is parsed as a single comma-separated list with no nesting,
(input a), (b), (c), (output d), (e), (f)
and sort out the relations between elements in some other way. I don't
understand the semantics, but hopefully, that should be no more
difficult than letting the port_direction propagate to later elements in
the list where the port_direction is omitted.
Maybe something like
simple_port
: IDENTIFIER
| '.' IDENTIFIER '(' expression ')'
;
directed_port
: attribute_list_opt port_direction simple_port
;
modport_ports_list
: directed_port
| modport_ports_list ',' directed_port
| modport_ports_list ',' simple_port
{ ... derive port direction (and attributes?) from preceding port ... }
;
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
|
|
From: Stephen W. <st...@ic...> - 2015-01-09 16:48:14
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
This problem has been solved in the parser for module ports.
Could your problem be the context where you are using the modport_item?
On 01/08/2015 11:33 AM, Martin Whitaker 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
>
- --
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iEYEARECAAYFAlSwBkMACgkQrPt1Sc2b3ikydwCgmi49m6UKM9btXVtU/EwIaeuN
caQAn1W4CCkfaZEutSDPotfUcq4tLddt
=b7NG
-----END PGP SIGNATURE-----
|
|
From: Martin W. <mai...@ma...> - 2015-01-09 20:32:50
|
Stephen Williams wrote:
> This problem has been solved in the parser for module ports.
OK, that's basically what I had in mind when I said I could solve this by
building my own mini state machine and parser within the modport_ports_list
rule (and what Niels suggested as well). It's a bit more complicated than the
module ports case, because you have modport expressions, task/function
import/export, and clocking declarations thrown into the mix. It's ugly, but
it works.
For anyone interested, the solution looks like this:
modport_ports_list
: modport_port_declaration
| modport_ports_list ',' modport_port_declaration
| modport_ports_list ',' modport_simple_port
{ if (last_modport_port != MODPORT_SIMPLE)
yyerror(@3, "syntax error");
}
| modport_ports_list ',' modport_tf_port
{ if (last_modport_port != MODPORT_TF)
yyerror(@3, "syntax error");
}
| modport_ports_list ',' IDENTIFIER
{ if (last_modport_port == MODPORT_CLOCKING)
yyerror(@3, "syntax error");
}
| modport_ports_list ','
{ yyerror(@2, "error: NULL port declarations are not allowed"); }
;
modport_port_declaration
: attribute_list_opt port_direction IDENTIFIER
{ last_modport_port = MODPORT_SIMPLE;
}
| attribute_list_opt port_direction modport_simple_port
{ last_modport_port = MODPORT_SIMPLE;
}
| attribute_list_opt import_export IDENTIFIER
{ last_modport_port = MODPORT_TF;
}
| attribute_list_opt import_export modport_tf_port
{ last_modport_port = MODPORT_TF;
}
| attribute_list_opt K_clocking IDENTIFIER
{ last_modport_port = MODPORT_CLOCKING;
}
;
modport_simple_port
: '.' IDENTIFIER '(' expression ')'
;
modport_tf_port
: K_task IDENTIFIER
| K_task IDENTIFIER '(' tf_port_list_opt ')'
| K_function data_type_or_implicit_or_void IDENTIFIER
| K_function data_type_or_implicit_or_void IDENTIFIER '(' tf_port_list_opt ')'
;
(and yes, I'll be putting in better error messages).
|
|
From: Cary R. <cy...@ya...> - 2015-01-09 23:35:25
|
And some comments explaining why you had to resort to all this would also be helpful. Not a full treatise, but something more than just the code would be appreciated.
On Friday, January 9, 2015 12:33 PM, Martin Whitaker <mai...@ma...> wrote:
Stephen Williams wrote:
> This problem has been solved in the parser for module ports.
OK, that's basically what I had in mind when I said I could solve this by
building my own mini state machine and parser within the modport_ports_list
rule (and what Niels suggested as well). It's a bit more complicated than the
module ports case, because you have modport expressions, task/function
import/export, and clocking declarations thrown into the mix. It's ugly, but
it works.
For anyone interested, the solution looks like this:
modport_ports_list
: modport_port_declaration
| modport_ports_list ',' modport_port_declaration
| modport_ports_list ',' modport_simple_port
{ if (last_modport_port != MODPORT_SIMPLE)
yyerror(@3, "syntax error");
}
| modport_ports_list ',' modport_tf_port
{ if (last_modport_port != MODPORT_TF)
yyerror(@3, "syntax error");
}
| modport_ports_list ',' IDENTIFIER
{ if (last_modport_port == MODPORT_CLOCKING)
yyerror(@3, "syntax error");
}
| modport_ports_list ','
{ yyerror(@2, "error: NULL port declarations are not allowed"); }
;
modport_port_declaration
: attribute_list_opt port_direction IDENTIFIER
{ last_modport_port = MODPORT_SIMPLE;
}
| attribute_list_opt port_direction modport_simple_port
{ last_modport_port = MODPORT_SIMPLE;
}
| attribute_list_opt import_export IDENTIFIER
{ last_modport_port = MODPORT_TF;
}
| attribute_list_opt import_export modport_tf_port
{ last_modport_port = MODPORT_TF;
}
| attribute_list_opt K_clocking IDENTIFIER
{ last_modport_port = MODPORT_CLOCKING;
}
;
modport_simple_port
: '.' IDENTIFIER '(' expression ')'
;
modport_tf_port
: K_task IDENTIFIER
| K_task IDENTIFIER '(' tf_port_list_opt ')'
| K_function data_type_or_implicit_or_void IDENTIFIER
| K_function data_type_or_implicit_or_void IDENTIFIER '(' tf_port_list_opt ')'
;
(and yes, I'll be putting in better error messages).
------------------------------------------------------------------------------
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
|
Thanks for helping keep SourceForge clean.
X