RE: [sv-bc] Task and function name binding

From: Francoise Martinolle <fm_at_.....>
Date: Thu Nov 20 2008 - 15:40:10 PST
I agree.


________________________________

	From: Mark Hartoog [mailto:Mark.Hartoog@synopsys.com] 
	Sent: Thursday, November 20, 2008 6:40 PM
	To: Francoise Martinolle; Mark Hartoog; sv-bc@eda.org
	Subject: RE: [sv-bc] Task and function name binding
	
	

	Francoise,

	 

	Your description is what I thought was intended, but the text
seems, at least to me, to say something different. It seems to say that
only the current scope is searched to the end for locally visible
symbols, rather than all the outer scopes too. 

	 

	From: Francoise Martinolle [mailto:fm@cadence.com] 
	Sent: Thursday, November 20, 2008 3:32 PM
	To: Mark Hartoog; sv-bc@eda.org
	Subject: RE: [sv-bc] Task and function name binding

	 

	 

	I believe that in your second example both function calls should
bind to top.b.f

	 

	In the algorithm I outlined in the first draft of the name
resolution, the current scope and upper scopes where searched

	in a while loop until no more scopes or a declaration was found.

	First the current scope is searched for local visible symbols,
then the imported packages at that scope,

	then current_scope wast set to upper scope and we started the
same search again.

	 

	The definition of the function f is in the first outer scope of
the named block. It appears in a scope that is closer to the

	named block than the scope where the import statement is found.

	 

	The basic difference between task/functions and other
identifiers, is that for task and functions the entire scope is
searched,

	for other identifiers only the declarations preceding the
reference matter.

	 

	Francoise

	       '

	 

		 

		
________________________________


		From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org]
On Behalf Of Mark Hartoog
		Sent: Thursday, November 20, 2008 5:48 PM
		To: sv-bc@eda.org
		Subject: [sv-bc] Task and function name binding

		I have been studying the language in 23.8.1 Task and
Function name resolution and 26.3 Referencing data in packages with
regards to task/function name resolution. Section 26.3 says:

		 

		<quote>

		For a reference to an identifier other than function or
task call, the locally visible identifiers defined at the

		point of the reference in the current scope shall be
searched. If the reference is a function or task call, all of

		the locally visible identifiers to the end of the
current scope shall be searched. If a match is found the reference

		shall be bound to that locally visible identifier.

		 

		If no locally visible identifiers match, then the
potentially locally visible identifiers defined prior to the point

		of the reference in the current scope shall be searched.
If a match is found, that identifier from the package

		shall be imported into the current scope, becoming a
locally visible identifier within the current scope, and

		the reference shall be bound to that identifier.

		</quote>

		 

		There is then this example in 23.8.1:

		 

		package p;

		    function void f();

		       $display("p::f");

		    endfunction

		endpackage

		 

		module top;

		   import p::*;

		   if (1) begin : b // generate block

		       initial f(); // reference to "f"

		       function void f();

		            $display("top.b.f");

		       endfunction

		   end

		endmodule

		 

		This example should print "top.b.f" which is consistent
with text in 26.3, but suppose I change this to:

		 

		package p;

		    function void f();

		       $display("p::f");

		    endfunction

		endpackage

		 

		module top;

		   import p::*;

		   if (1) begin : b // generate block

		       initial  begin : block

		           f(); // reference to "f"

		       end

		       initial f();// reference to "f"

		       function void f();

		            $display("top.b.f");

		       endfunction

		   end

		endmodule

		 

		There is now an additional  reference to 'f' in the
named block 'block', which is a scope. At the end of the scope 'block'
there is no 'f' defined locally. Does this now make 'p::f' locally
visible in module top and then bind the function call to 'p::f' so that
this now print "p::f"? 

		 

		Was the intent here that these two calls to f() should
bind differently without producing any error message?

		 

		 

		
		-- 
		This message has been scanned for viruses and 
		dangerous content by MailScanner
<http://www.mailscanner.info/> , and is 
		believed to be clean. 


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Thu Nov 20 15:42:46 2008

This archive was generated by hypermail 2.1.8 : Thu Nov 20 2008 - 15:42:56 PST