FW: [sv-bc] parameterized structures

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?

>  One implication of this is
> that a static pre-elaboration "name mangling" approach as used
> in C++ can't work in SV.

Name mangling is nothing more than an encoding of the scope and structural 
info needed to uniquely characterize each type.  The exact rules for type 
identity in SV and in C++ are a bit different, but in both cases there is 
a finite amount of info that must be known before the type comes into existence 
and which can be encoded into a "mangled name".  Mangled names can become 
as interesting as Gödel numbers if you let them.

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.  For instance, if the language provides 
a facility for deriving new types on the fly which exploit the differences 
between distinct dynamic objects ( ones created only by the running simulation), 
then those new types could not possibly be compiled during elaboration phase.
Gödel does have a proof about "incompleteness" of many formal systems.

But even dynamically invented types can be given unique mangled names - provided 
you found a way to unambiguously encode the identity of the dynamic objects 
that contribute to their definition.

Classes and structs in SV are *more* different than they are in C++.
The key element being the automatic dynamic memory management of SV class objects 
which is unlike C++ and is not needed for SV static structs.
Parameterizing structs does not make them dynamic, however.  So this 
difference is preserved even if struct syntax is extended in this way.

Greg