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

Steven, I think your description is a bit misleading.

The first pass isn't really just lexical imports.

For example, the case that fails in that approach is the following:

   package p;
     function int f();
       return 1;
     endfunction
   endpackage

   module top;
      import p::*;
      if (1) begin:b
         int x = f();         // what am I
         function int f();
           return 2;
         endfunction
      end
   endmodule

If you do a pure lexical import alg first, you bind f in
"what am I" to p::f; I am sure that you agree that is incorrect.


So, here is what I think an approximate "simple algorithm" is
for non-method tf name reference:

    At the point of reference, consider all current potentially visible
    names from imports in the current lexical scope (i.e. those from imports
    prior to the point of reference).  If there is a match we're done.  If
    not, at the close of the scope determine if "f" now matches in the scope.
    If so, that is the match and we're done.

    If not, close the scope and treat the "point of reference" for
    "f" as being the point at which the scope closes.  Repeat the above
    process as scopes close.  If $unit closes without a resolution
    of the name "f", then it is a truly upwards hierarchical reference
    in the instance tree.

I think that correctly covers all of the situations and intent of
normal (non-method) function and task resolution.  I certainly is
the most concise way I've come up with to describe what I believe
is the intent of the rules.

Gord.

Steven Sharp wrote:
>> 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
> 
> 

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


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