Re: [sv-bc] Ambiguity in function prototype parsing

That is a good point Mark.  There is one other aspect though --
if "function void test(input T T[1:0])" is legal (which it
should be I think), then the normal rule of "you can drop
the formal name in the prototype" doesn't work.  So either way
you have an odd case.  I think that I agree that with your
example, rule 3 is less odd overall.

Gord.


Mark Hartoog wrote:

> If "function void test(input T[1:0])" was in a function definition,
> where the port name must be given, 'T' would be the port name.
> 
> I think it is a bad idea to make up different parsing rules so that
> the legal, unambiguous function definition header is illegal as
> a prototype or means something different in a prototype than
> what it means as a function header, so I thing 3 is the best
> choice.
> 
> By the way, I think allowing unnamed ports in function prototypes
> is a bad idea. C/C++ allows this, but C/C++ does not have 
> function calls with argument passing by name.
> 
> 
>>There appears to be a true ambiguity in SV regarding how to 
>>parse function prototypes.  Consider:
>>
>>   typedef int T;
>>   module top;
>>     import "DPI-C" function void test(input T[1:0]);
>>   endmodule
>>
>>   class C;
>>     extern function int test(T[1:0]);
>>   endclass
>>
>>
>>I think that per the LRM both of these should be legal.  Note 
>>that for a function prototype, the name of the formal is not 
>>required.  In addition, the type is not required (implicitly 
>>logic).  So, what does "T[1:0]" mean?  Does it define a 
>>formal named "T" with type of unpacked array of logic or does 
>>it define an unnamed formal of type unpacked array of T?
>>
>>There are several ways to deal with this:
>>   1) if the identifier is a visible type, require a full type
>>      and name declaration for the formal
>>   2) if the identifier is a visible type, treat the declaration
>>      as an explicitly typed unnamed formal
>>   3) always treat this as an implicitly typed named formal
>>
>>I think that I'd like to require either 1 or 2.
>>
>>There are some parallels to this issue in the port 
>>declaration space, but I believe that they can all be 
>>disambiguously interpreted (although they aren't LALR(1)).  
>>If we do go with (1), I'd probably like to take another look 
>>at the port declaration rules in order to require full 
>>declarations in any cases that might be surprising to the user.
>>
>>Gord
>>--
>>--------------------------------------------------------------------
>>Gordon Vreugdenhil                                503-685-0808
>>Model Technology (Mentor Graphics)                gordonv@model.com
> 
> 

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com