From: Daryl Stewart (Daryl.Stewart@cl.cam.ac.uk)
Date: Mon Dec 03 2001 - 03:38:59 PST
Precedence: bulk
<p>> Hi Daryl,
>
> I believe that the mintypmax expression after a # must always be enclosed
> in parentheses. So your grammar is wrong, and
>
> i <= # a | b | c;
> is equal to:
> i <= #(a) ((| b) | c));
>
> Peter.
Absolutely Peter, except that it's not *my* grammar, it's the standard's
grammar, and as such should either be unambiguous or clarified in the text of
the standard.
My point was that the grammar as defined in 1364 _can_ have more than one
parse tree generating that particular string of tokens, hence the standard
defines an ambiguous grammar. Unless there is a paragraph stating that "the
mintypmax expression after a # must always be enclosed in parentheses" (as I'd
always assumed myself ;).
I was hoping that someone would point out that I'd copied the grammar
incorrectly from the latest draft (not to hand) or that there is indeed such a
statement in the body of the standard confirming our shared belief.
We really shouldn't use delay_value to define delay_control, or we should
provide extra rubrics.
<p>Also, as has been pointed out many times, the correct parse of
repeat (e) @(...) statement
May be a delay_or_event_control followed by a statement
or a loop_statement
and I still can't find a rubric disambiguating this.
<p>If the standard fails to disambiguate the grammar, these questions will become
FAQs. Just because "everyone knows the answer" doesn't mean it shouldn't be
part of the standard...
cheers
Daryl
>
> At 05:24 PM 11/30/01 +0000, Daryl Stewart wrote:
> >Precedence: bulk
> >
> > > it makes it easier to reason about grammars.
> >
> >On that subject, can anyone tell me if I'm wrong that the following syntax is
> >ambiguous:
> >
> >nonblocking_assignment ::= variable_lvalue <= [ delay_or_event_control ]
> >expression
> >
> >delay_or_event_control ::=
> > delay_control
> > | event_control
> > | repeat ( expression ) event_control
> >
> >delay_control ::=
> > # delay_value
> > | # ( mintypmax_expression )
> >
> >delay_value ::=
> > unsigned_number
> > | parameter_identifier
> > | specparam_identifier
> > | mintypmax_expression
> >
> >mintypmax_expression ::=
> > expression
> > | expression : expression : expression
> >
> >There's an ambiguity in the grammar since we can have
> > variable_lvalue <= # expression expression
> >so is:
> > l <= # a | b | c;
> >equal to:
> > l <= #(a) ((| b) | c));
> >or:
> > l <= #(a | b) (| c);
> >
> >delay_value used to have constant_mintypmax_expression instead of
> >mintypmax_expression, which is no better really, and Verilog-XL refuses:
> > l <= # 1:2:3 e;
> >and requires:
> > l <= #(1:2:3) e;
> >anyway.
> >
> >delay_value must (?) allow mintypmax_expression for when it is part of a
> >delay2 or delay3, which is never ambiguously followed by an expression.
> >
> >One solution is for delay_control to become
> >
> >delay_control ::=
> > # unsigned_number
> > | # parameter_identifier
> > | # specparam_identifier
> > | # ( mintypmax_expression )
> >
> >cheers
> >Daryl
>
>
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:54:48 PDT
and
sponsored by Boyd Technology, Inc.