Gord, I'm sure I don't know the committees' full intent on these issues. As a former C++ vendor, now involved with SV synthesis, I'm more curious than knowledgable about how classes fit into SV. The classes defined by the current LRM seem sound so far as they go. I think this discussion is only valuable as an exploratory tangent to help us all appreciate the implications of alternate ways class types might be parameterized in the future. The immediately pertinent questions should concern function parameterization and the open ballot issue. Do you think passage of #225 prematurely settles questions that clearly need more discussion? Greg Gordon Vreugdenhil wrote: > > 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. >> >> >> >> >Received on Fri May 6 11:31:20 2005
This archive was generated by hypermail 2.1.8 : Fri May 06 2005 - 11:31:40 PDT