Re: FW: [sv-bc] parameterized structures

Thanks for the clarification, Gordon!  I see the governing sentence now:

> In [non-compilation-unit] contexts, such as modules or programs, each instance
> of the scope  containing the generic class declaration
> creates a unique generic class,
> thus, defining a new set of matching specializations.

This reinforces something said in 6.9:

> The scope of a data type identifier shall include the hierarchical instance scope.
> In other words, each instance with a user-defined type declared inside the
> instance creates a unique type.

You're right, this /is/ something completely different from C++.  I don't
think it is a difference between structs and classes in SV, though.

I would just realized that this makes the concept of static local variables
of a local struct type utterly useless.  So useless, it is probably worth
a warning message.  No future (or recursive) call to the function will declare
a matching struct type, so the static variable can't possibly be used to
communicate amongst call sites.

This seems to be governed by a NEW unwritten rule:  The lifetime of a variable
cannot exceed the lifetime of its type.   Which opens a Pandora's box of questions.

The modifier "static" can only apply to the storage for the variable.  It's too
late to have it apply to the type underlying the typedef which is being used
in the declaration of the variable...  But if the type will is unique to some
surrounding scope instance, does this imply that the static lifetime is
the same as an automatic variable of the same scope as the data type?

I don't think we've tried enforcing such a rule to date... My inclination would
be to error on the combination of static lifetime and perishable type, at least
until the LRM rules on the subject.

Greg Jaxon


Gordon Vreugdenhil wrote:
> 
> 
> Bresticker, Shalom wrote:
> 
>> Resend for Greg
>>
>> -----Original Message-----
>> From: owner-sv-bc@server.eda-stds.org 
>> [mailto:owner-sv-bc@server.eda-stds.org] On Behalf Of Greg Jaxon
>> Sent: Friday, June 16, 2006 10:38 PM
>> To: Gordon Vreugdenhil
>> Cc: sv-bc@server.verilog.org
>> Subject: Re: [sv-bc] parameterized structures
>>
>> Gordon Vreugdenhil wrote:
>>
>>
>>> There is another important difference -- C++ doesn't have the
>>> additional "elaboration" phase that Verilog has and as a result
>>> essentially all "template" analysis is a compile time
>>> activity. 
>>
>>
>> C++'s template instantiation phase is driven by a fixed-point linking
>> discipline that is essentially identical to design elaboration.  The 
>> compiler is not done cranking out template instantiations until no new 
>> ones are demanded and the last one is specialized.
>>
>>
>>> In SV, different elaborations of a parameterized
>>> class create different universes for instantiation.
>>
>>
>> I don't understand the phrase "different universes for instantiation".
>> Of course each parameterization of an SV class, like a C++ template 
>> class specialization, produces a particular class (a new data type) 
>> which then governs the behavior of a family of class instances.  
>> That's like a universe in which you can construct new instances...
>>
>>
>>> There is no corresponding concept in C++.
>>
>>
>> Which could be why I am not recognizing it. Are you sure that brief 
>> section 7.23 is inventing something new under the sun?
> 
> 
> The issue here is in the following desgin:
> 
>   module top;
>     child c1();
>     child c2();
>   endmodule
> 
>   module child;
>     class C #(int p = 1);
>     endclass
> 
>     C #(2) c_obj;
>   endmodule
> 
> The two *elaborated instances* of child produce distinct
> parameterized classes where each will end up with one specialiation.
> The two specializations are distinct; one is based on the parameterized
> class in top.c1 and the other is based on the parameterized class
> in top.c2.  Each elaboration of child creates a new universe of
> specializations related to the elaboration of the new parameterized
> class.
> 
> This means that top.c1.c_obj is not assignment compatible with
> top.c2.c_obj.
> 
>> If you can prove that no name-mangling approach will ever work for SV, 
>> then the game is up - the language is simply uncompilable.
>> This might be a true statement.  
> 
> 
> I said that no *static pre-elaboration* name mangling can work.  In other
> words, it is not possible to independently compile "child" and create a
> fixed universe of types since each elaboration time instantiation
> of "child" creates additional types that are required to be distinct.
> 
> Clearly all of this is compilable (existence proofs exist), it is
> just a bit more dynamic than one might think.
> 
> Gord.