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

Hi Gordon,
The algorithm you defined seems to me same as mine. What do you think?

Regards
Surya



-------- Original Message  --------
Subject: Re:[sv-bc] Task function identifier searching rule
From: Gordon Vreugdenhil <gordonv@model.com>
To: Steven Sharp <sharp@cadence.com>
Cc: spsaha@cal.interrasystems.com, sv-bc@eda.org
Date: Tuesday, January 13, 2009 12:08:02 PM
> 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
>>
>>
>




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