Re: [sv-ec] dynamic vars should be forbidden as defaults

From: Neil Korpusik <Neil.Korpusik_at_.....>
Date: Wed Jan 23 2008 - 14:08:38 PST
This is now Mantis item 2245.

Neil



Arturo Salz wrote:
> I see your point and I tend to agree with you.
> 
>  
> 
> Actual arguments are not part of a method. As the pseudo-code in my 
> previous message shows, arguments are evaluated in the caller – before 
> making the method call. Hence, using “this” either explicitly or 
> implicitly (i.e., your f1 is essentially x=this.a) should not be 
> allowed. The intent of the LRM statement was to use the **static** scope 
> for resolution of constants. I’d be willing to add this to the LRM if 
> other agree.
> 
>  
> 
>             Arturo
> 
>  
> 
> ------------------------------------------------------------------------
> 
> *From:* danielm [mailto:danielm@aldec.com.pl]
> *Sent:* Monday, January 21, 2008 1:07 AM
> *To:* 'Arturo Salz'; sv-ec@eda.org
> *Subject:* RE: [sv-ec] dynamic vars should be forbidden as defaults
> 
>  
> 
> OK - I understand yours example - it is fine for me - thanks for 
> explanation.
> 
>  
> 
>  
> 
> But what about my code - is it legal or not - the LRM doesn't forbid 
> below (case f1,f2).
> 
>  
> 
> class C;
> 
>   int a;
> 
>    static int b;
> 
>     function f1(int x=a);
> 
>    endfunction
> 
>     function f2(int y=this);
> 
>    endfunction
> 
>     function f3(int z = b);
> 
>    endfunction
> 
> endclass
> 
>  
> 
> IMHO only the 3rd (f3)should be allowed - because defaults are assigned 
> before the function call - so only statics are known at that moment.
> 
>  
> 
>  
> 
>  
> 
> DANiel
> 
>  
> 
> ------------------------------------------------------------------------
> 
> *From:* Arturo Salz [mailto:Arturo.Salz@synopsys.com]
> *Sent:* Saturday, January 19, 2008 12:20 AM
> *To:* danielm; sv-ec@eda.org
> *Subject:* RE: [sv-ec] dynamic vars should be forbidden as defaults
> 
> Daniel,
> 
>  
> 
> The segment you highlighted refers only to name binding – not to lifetime.
> 
>  
> 
> So considering the following code:
> 
>  
> 
> int a;
> 
> class C;
> 
>   function void f1(int x=a);
> 
>     // ...
> 
>   endfunction
> 
> endclass
> 
>  
> 
> initial begin
> 
>   bit a;
> 
>   C c1 = new;
> 
>   c1.f1();
> 
> end
> 
>  
> 
> The method call could be “conceptually” implemented as:
> 
>  
> 
> initial begin
> 
>   bit a;
> 
> C c1 = new;
> 
> int temp = $unit::a;
> 
> c1.f1( temp );
> 
> end
> 
>  
> 
> Note that the argument binds to the variable in $unit– the “a” in the 
> declaration – and not the “a” in the scope of the call.
> 
> That is what that statement indicates.
> 
>  
> 
> Arturo
> 
>  
> 
> ------------------------------------------------------------------------
> 
> *From:* owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] *On Behalf Of 
> *danielm
> *Sent:* Friday, January 18, 2008 7:19 AM
> *To:* sv-ec@eda.org
> *Subject:* [sv-ec] dynamic vars should be forbidden as defaults
> 
>  
> 
> LRM says that: 
> 
> 1800-2005: 12.4.3 Default argument values:
> 
> "The default_value is an expression. The expression is **evaluated in 
> the scope containing the subroutine**
> 
> **declaration** each time a call using the default is made."
> 
>  
> 
> The problem arises when we use that rule for dynamic|automatic variables 
> - ie for class propeties:
> 
> class C;
> 
>   int a;
> 
>    static int b;
> 
>     function f1(int x=a);
> 
>    endfunction
> 
>     function f2(int y=this);
> 
>    endfunction
> 
>     function f3(int z = b);
> 
>    endfunction
> 
> endclass
> 
>  
> 
> IMHO only the 3rd (f3)should be allowed - because defaults are assigned 
> before the function call - so only statics are known at that moment.
> 
>  
> 
>  
> 
> Similar case may be also spotted in example with no classes:
> 
> module top; 
>  task **automatic** t(int a = 1, int b = a); 
>   $display(a,,b);
>  endtask     
>  
>  initial t;
> endmodule
> 
>  
> 
>  
> 
> In above case a is an automatic variable and doesn;'t exists at the 
> moment when defaults should be assigned.
> 
>  
> 
> DANiel
> 
> 
> -- 
> This message has been scanned for viruses and
> dangerous content by <http://www.mailscanner.info/>*MailScanner* 
> <http://www.mailscanner.info/>*, and is
> believed to be clean. *
> 
> *
> -- 
> 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 Wed Jan 23 14:09:09 2008

This archive was generated by hypermail 2.1.8 : Wed Jan 23 2008 - 14:09:31 PST