Re: [sv-ec] class extension across hierarchical boundaries

Arturo Salz wrote:
[...]
> 
> Parameterized classes (similar to parameterized modules) evidently 
> depend on the parameter resolution and thus on the design elaboration. 
> For such classes, the compiler has no choice but wait until a particular 
> class specialization is seen before code can be generated for the class. 

Ok so far.

> If we allow extension of classes (with static references) across the 
> module instantiation hierarchy then _all classes_ become dependent on 
> the post-elaborated model. 

This I don't agree with, at least not if I am understanding you
correctly.  See below.


 > As I wrote before, this dependency forces
> compilers to either (a) wait until post-elaboration to generate separate 
> code for classes, or (b) generate generic class code that includes the 
> static variable lookup. In my opinion, this dependency was not allowed 
> by the previous LRM. If you believe otherwise then clearly the LRM is 
> ambiguous and we should explicitly document this on way or the other.

I don't believe the LRM restricted this anymore than it restricted the
extension of a type parameter of a parameterized class -- there is
no indication at all that the LRM views type parameters *differently*
in a module context versus a package/parameterized class context.
That is what you are suggesting and I don't agree that there is any
hint of such a difference in the LRM.




On a technical basis, I'm don't agree that _all classes_ would have an
elab dependency.

Certainly if you have a class such as the following:
    package p;
      class c;
         static int x;
         function int get_it(); return x; endfunction
      endclass
    endpackage
I don't think that "c" ever has the issue that you are worried about.

Let's try this example -- given the above, consider the following:

    // in a package context
    class d extends c;
       static int y;
    endclass

    // versus in a type parameter context
    module M #(type T = p::c);
      class e extends T;
         static int y;
      endclass
    endmodule

My claim is that there is only ONE c::x and that
c::x, d::x and e::x all refer to it.  Do you agree with that?
It not, we have a serious disconnect.

If so, then why do you think "c" needs to change at all due
to its use in e via a type parameter?

Certainly one has to be careful about "e" since its
static "y" is module instance dependent, but we have
that problem in any case.


It is certainly also true that if you have a class in
a module and pass it as a type parameter to another
module that you have to be careful in implementation but
you should only have to pay for that cost when you need to.

Using my earlier version of "M", consider:
    module something;
      class G;
         static int x;
      endclass
      M #(G) m();
    endmodule

 From an *implementation* stand point, I agree that
"G" is a bit different than extending "c" since the
extension in "M" must be aware of both true "singleton"
statics (i.e. from C) and instance-specific statics
(i.e. from G) but I don't see why this *needs* to impact
"c" in any way.  I can certainly understand why an
implementation might want to ease implementation in
such a manner, but I certainly don't agree that it is
*required*.


Further, it is clear that one can mimic at least the
code dependency issues in other ways using type parameters
and functions.  So I don't see that there is anything
really different in terms of the implementation
requirements in such cases versus the class inheritance
cases that you are worried about.


Having been directly involved in an implementation that
handles all such situations, I still do not agree that
there is any fundamental issue or difference.  Clearly
some classes (such as parameterized classes) need to
have post-elab knowledge; clearly others do not (certain
classes in packages).  Extending from a module type parameter
is just another case of needing elab knowledge.  Such
knowledge is needed in other cases (parameter dependent
structs, etc) so there is nothing fundamentally different
here in terms of the LRM expectations.

Gord.

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.