Re: [Iverilog-devel] Is there any way to avoid this shift/reduce conflict?

[<ni...@ly...>]

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.