Re: [sv-bc] Serious issue with default expressions for task and function arguments

Mark Hartoog wrote:

> "The elements of the expression must be visible at the scope of subroutine
> and, if used, at the scope of the caller."
> 
> My interpretation of this was that all identifiers in the expression
> had to resolve to the same object (element) in both the subroutine scope 
> and the caller scope. 

That is not what the text says however.

In my case, "p1" is visible at the scope of the subroutine and at
the scope of the call.  There is no stated obligation that they
must be the same object.

If there is an obligation for the names to be the same object,
then the requirement of resolving the name in the caller's scope
is meaningless since the name is required to be resolved in the
context of the routine as well.  In that case, simply removing
the text related to visibility in the scope of the caller would
end up with the same effect (and would resolve my concerns).  The
fact that the current text does differentiate works against your
argument.

Gord.

 > So in your example:
> 
> 
>>    module A;
>>       parameter p1 = 1;
>>       function integer f(integer x = p1) ......
>>    endmodule
>>
>>    module B;
>>       real p1;
>>       A a();
>>       initial $display(a.f);
>>    endmodule
> 
> 
> the call would be illegal because in the calling scope 'p1' does 
> not resolve to the parameter 'p1' in the module 'A'. 
> 
> The only way to make this legal would be to make the default 'B.a.p1',
> which would resolve the same in both scopes. As a practical matter, 
> non-constant default values are probably not useable on hierarchical
> task and function calls, but I do not see any problem with that
> since I expect most default values will be constants.
> 
> We could change the language of that section to make this clearer.
> 
> Mark Hartoog
> 700 E. Middlefield Road
> Mountain View, CA 94043
> 650 584-5404
> markh@synopsys.com  
> 
> 
>>-----Original Message-----
>>From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org]On Behalf Of
>>Gordon Vreugdenhil
>>Sent: Thursday, March 03, 2005 8:49 AM
>>To: ieee1800@eda.org; SV_BC List
>>Subject: [sv-bc] Serious issue with default expressions for task and
>>function arguments
>>
>>
>>
>>While reviewing aspects of the draft SV standard, we came across
>>the following in Section 11.4.3 (Default argument values [Tasks and
>>Functions]):
>>
>>    The default_value is an expression. The expression is evaluated in
>>    the scope of the caller each time the subroutine is called. The
>>    elements of the expression must be visible at the scope of subroutine
>>    and, if used, at the scope of the caller. If the default_value is not
>>    used, the expression is not evaluated and need not be visible at the
>>    scope of the caller.
>>
>>
>>The LRM requires that the terms of the default expression to be resolved
>>in the context of the **caller**.  This is not at all reasonable
>>as a general programming language semantic definition, nor in
>>the context of separate compilation and hierarchically referenced
>>tasks and functions.
>>
>>Consider obvious examples such as:
>>
>>    module A;
>>       parameter p1 = 1;
>>       function integer f(integer x = p1) ......
>>    endmodule
>>
>>    module B;
>>       real p1;
>>       A a();
>>       initial $display(a.f);
>>    endmodule
>>
>>The LRM currently requires that actual parameter value used in
>>the call of a.f will be the value of "p1" from B.p1.
>>
>>Although in the context of synthesis, one could conceivably make
>>an argument that this "macro" view of default values might be
>>useful (since hierarchical calls aren't allowed), in the context
>>of simulation, this is not reasonable.
>>
>>This issue will be raised as part of Mentor's official response, but
>>I wanted to raise this immediately since we consider this to be
>>a very significant flaw.
>>
>>Gord
>>-- 
>>--------------------------------------------------------------------
>>Gordon Vreugdenhil,  Staff Engineer               503-685-0808
>>Model Technology (Mentor Graphics)                gordonv@model.com
>>

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