Re: [sv-bc] Task function identifier searching rule

>From: Surya Pratik Saha <spsaha@cal.interrasystems.com>

>So I am just writing a complete 
>algorithm in my own way to find out the identifier for task enable and 
>function call:
>
>-- Search the identifier in the current name space/scope completely and 
>any wild card import statement present lexically before that in the same 
>scope.
>-- If not found, go upper lexical scope to do the complete search, wild 
>card import statement to be considered which are present lexically 
>before the current name space/scope.
>-- Repeat above rule until not found.
>
>Please confirm if my understanding correct.

The problem with this is that you are trying to resolve task and function
names in one pass.  The actual algorithm is based on more than one pass.

The first pass is the normal one for simple identifier names.  It will
only find names declared before this reference, or imports seen before
this reference.  It goes from innermost lexical scope outward.  This pass
can cause names to be imported.

If the name is not found, and it is a task or function name, then it is
considered to be a hierarchical name, and its resolution is deferred until
later.

When a task or function name is resolved hierarchically, it uses the
normal resolution for hierarchical names.  This searches nested scopes
until it reaches the module level, after which it starts searching up
from the point of instantiation, repeating this as necessary.  During
this search, all names in the scope are considered, regardless of the
position of the declaration.  It is this pass that gives you the ability
to make forward references to tasks and functions.

As I understand it, this second pass does not consider imported names,
nor will it cause any names to be imported.

Each of these passes is relatively simple.  Again, the first one is the
normal one for simple identifiers.  The second one is the normal one for
hierarchical names.  It is only the fact that both get applied to task
and function names that makes the result seem complex.  This is especially
true if you insist on trying to define the rules in terms of a single
complicated pass instead of two simpler ones.

Unfortunately, this has been made more complex.  The hierarchical search
for task and function names gives the appearance of allowing forward name
references.  However, the hierarchical search does not look into the
$unit scope.  That is only searched during the first lexical scope
search.  That does not allow forward references into the $unit scope.
Some people felt that this should be allowed.  So now a kludge rule
has been added to allow it, which turns the simple special rule
"Treat unresolved task and function names as hierarchical names", into
a much more special case.


>I am not sure whether it is right platform or not to discuss, but I 
>think implementing this is tough though, as we need to defer the 
>searching until whole design is processed and the corresponding object 
>model is populated. Also we need to keep a list of wild card import 
>statements present lexically before and associate this with each nested 
>scope and function call/task enable.

You believe this because you are trying to come up with an algorithm
that can do this in one pass.  Breaking this into two passes simplifies
these issues. 

The second pass is the hierarchical name resolution pass.  It always
needed to be deferred until the whole design was processed (though it is
possible to do an early attempt to resolve any hierarchical names that
can be resolved locally to the module, and only defer the rest).  So
this adds no complexity that did not already exist.

The tracking of imports only needs to be done in the first pass.  They
are not needed after that, since the later pass does not use them.
The "lexically before" rule is rather easy to handle in this pass.  Do
a pass in lexical order, making symbols and import statements available
when their declarations are processed, and resolving names against these
available symbols and imports when each reference is processed.

Steven Sharp
sharp@cadence.com


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.