Greg, there are additional questions that pose serious issues once one goes the route of "C++ like sharing". Some issues that I don't understand: 1) under what conditions would class types be distinct? In other scenarios, Arturo has made a big deal about non-compatibility of types across various kinds of system hierarchy (program/module being the most clear). So are class specializations really intended to require a global analysis and go across any boundaries? If not, under what conditions would variants not be considered equatable? 2) What are the rules by which one determines the equivalence of two variants? C++ has definite rules that are normally used to create managled names at compile time. The main consistency check is a link-time name uniqueness and existence check. In Verilog, given elaboration semantics, no simple name mangling approach will be sufficient. What rules then are to be used? A "===" check on the final value of class value parameters and a matching type check on type parameters? From background discussions with Arturo, I don't think that is what he expects, but I don't know what he does want. 3) Are parameterized class types within a module supposed to be considered variants and unified? What if there are other module instance dependencies in the parameterized class? I would expect that a parameterized class within a module instance would form a separate domain for variantions. Since C++ has no comparable concept, it isn't at all clear what the correspondence should be. The conditions under which non-parametric dependencies form an implicit part of the variation determination need to be specified. These are the most serious questions; I could likely come up with more but the answers to the above would set up a consistent conceptual framework about which one might be able to reason. The "instantiation route" that I read into this section makes these questions moot -- the model for instantiation is clear in Verilog. Although I certainly agree that an instantiation model is less than ideal for various scenarios, at least how it works is well defined. If the C++ like route is really what was intended, how could one possibly implement to that expectation without having at least the above issues codified in the LRM? The statement that "this is just like C++" is nowhere near an implementable specification given the additional kinds of questions that arise in the elaboration model. Gord Greg Jaxon wrote: > Gord is justifiably confused about class specialization. > Elsewhere the LRM has insisted that: > > 1) struct { int a,b,c } a; > struct { int a,b,c } b; // have different type > > 2) Distinct interface instantiations (even with identical > parameters) are distinct interfaces, which do not share > their static declarations. > > Specialization of classes needs to break this pattern so that > parameterized modules don't have to also receive the correspondingly > specialized classes they'll exercise. We want generic modules to refer to > generic class specializations as needed by simply repeating the > specializing syntax. It's going to be up to some linkage step to > unify all the static members of specialized classes. Classes are > levers for operating the linkage machinery. > > I'm pretty sure that is the design intent. The LRM text has not > been sufficiently definitive here if it has confused so careful > a reader as Gord. > > I expect that static objects connected this way are not synthesizable. > > Greg > > Brad Pierce wrote: > >>> Gordon Vreugdenhil wrote: >>> >>> Arturo Salz wrote: >>> >>>> Are you seriously suggesting that in >>>> this example, objects a and b are different types? >>>> >>>> C#(5) a = new; >>>> C#(5) b; >>>> >>>> b = a; // is this illegal? >>> >>> >>> Absolutely. >>> >>> If you want the types to be the same, you must create a typedef >>> that makes a unique instantiated type. >>> >> >> >> Then, what about >> typedef C#(5) c_5; >> Would you suggest that C#(5) and c_5 are incompatible types? >> Consider the matching type rules: >> >> 2) A simple typedef or type parameter override that renames a >> built-in >> or user-defined type matches that built-in or user-defined type >> within >> the scope of the type identifier. >> >> 4) A typedef for an enum, struct, union, or class matches itself and >> the type of data objects declared using that data type within the >> scope of the data type identifier. >> >> I take that to mean that x and y below are matching types: >> c_5 x; >> C#(5) y; >> But, I guess you'd argue that they are incompatible. > > > -- -------------------------------------------------------------------- Gordon Vreugdenhil, Staff Engineer 503-685-0808 Model Technology (Mentor Graphics) gordonv@model.comReceived on Thu May 5 21:34:53 2005
This archive was generated by hypermail 2.1.8 : Thu May 05 2005 - 21:35:00 PDT