Subject: Re: [sv-cc] Meeting reminder 07/22/03 - BNF for dpi_function_proto
From: Andrzej Litwiniuk (Andrzej.Litwiniuk@synopsys.com)
Date: Wed Jul 23 2003 - 07:30:48 PDT
> o Agenda:
>
> - Action item# 1: BNF issue [Andrzej, 20 minutes].
> (1385.html)
Team,
First, I have to apologize for being late with my action item.
Second, let us recall that there is an alternative approach for defining
grammar rules for DPI, a bifurcation, with specialized productions.
Doug seems to be a strong proponent of this approach and IMO it would be fair
to discuss all pros and cons before jumping onto 'unified' solution that
Joao and myself proposed.
Here is the proposed fix to the BNF.
Replace all existing rules for dpi_function_proto with one production only:
dpi_function_proto ::= function named_function_proto
and add a semantical rule that tf_ref_declaration is not permitted.
Pls. note that some semantical restrictions are needed anyway, for example
not all types/sizes are permitted for DPI.
Rationale:
- this is consistent with other productions, e.g.
method_prototype ::= function named_function_proto
- the existing grammar has two flows (in addition to missing "function")
- ambiguity because there are two alternative derivations
- allows tf_ref_declaration that should not be permitted
I'm also very tempted to propose some simplifications (factorization mainly)
of other parts of BNF.
For example, the group of four symbols tf_{input|output|inout|ref}_declaration
occurs 6 times, while it could be derived from a common symbol.
There are also some inconsequences, {attribute_instance} is coupled with a symbol in some productions, but pulled out in other productions.
Thanks,
Andrzej
This archive was generated by hypermail 2b28 : Wed Jul 23 2003 - 07:32:09 PDT