Re: FW: [sv-bc] parameterized structures

From: Gordon Vreugdenhil <gordonv_at_.....>
Date: Mon Jun 19 2006 - 11:42:41 PDT
Greg Jaxon wrote:

> I agree that the type universe is statically computable at
> elaboration time.  

Good.

 > I guess the "lifetime" I'm referring to
> is the sequential lifetime of scopes during elaboration.
> 
> function automatic string foo();
>   typedef struct { int wont_get; } food_again;
> 
>   static food_again new_boss;
> 
>   new_boss.wont_get = 32'shdeadbeef;
> 
>   return $typename( new_boss );
> endfunction
> 
> Each time this function is called, we get a new "instance" of its scope, 
> right?

I don't think so.  You really need to think of "typedef" as being
"static typedef".  There are no "automatic" types -- this is implied by
the earlier statement that all types are computable at elaboration time.
This also allows "static food_again new_boss;" to have a sensible
and unsurprising meaning.

Gord.

> So each new_boss has a different type than the old new_boss, right?
> 
> Greg
> 
> Gordon Vreugdenhil wrote:
> 
>> Greg,
>>
>> I think that you are assuming something stronger than what the
>> LRM requires.  Class specialization requires *constant* values;
>> as a result, the *type* universe is computable at elaboration
>> time and doesn't grow during simulation.  "static" is useful
>> since a type doesn't really come and go -- the local visibility
>> does but not the type itself.
>>
>> Example:
>>
>>   module top;
>>     class C #(int p = 1);
>>        static int x;
>>     endclass
>>
>>     function void foo;
>>        C #(2) local_obj;
>>     endfunction
>>
>>     C #(2) c_obj;
>>   endmodule
>>
>> The type of "local_obj" in foo is *the same type* as the type
>> for c_obj.  Any reference to "x" via either local_obj or
>> c_obj always refers to the same "x" that is tied to the specialization
>> of the type within the universe of class C.
>>
>> This means that any recursive call could still only create
>> an elaboration time determinable universe of types.  It is an
>> implementation issue about when the specializations actually
>> occur but the static members never "go away".  The lifetime
>> of a static class member conceptually extends from the first
>> time the type is specialized until the end of simulation;
>> any future specialization has the same static member.
>>
>> Gord.
> 
> 
> 

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com
Received on Mon Jun 19 11:42:45 2006

This archive was generated by hypermail 2.1.8 : Mon Jun 19 2006 - 11:42:55 PDT