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

Gord,

 

Response below,

 

            Arturo

 

-----Original Message-----
From: Gordon Vreugdenhil [mailto:gordonv@model.com] 
Sent: Monday, October 22, 2007 7:53 AM
To: Arturo Salz
Cc: sv-ec@eda.org
Subject: 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.

 

 

[AS] As I write in my original message (when we were discussing the 2005
LRM) I certainly considered 

this type of extension problematic and argued that it _should not be
allowed_. Hence, my assumption

was that it was not allowed unless explicitly stated so in the LRM.
Since it is not even supported by an

example, we assumed that this was not legal. I don't think this is a
constructive argument - I am surely

not going to change my mind as to what I believed to be true in the
past. You should acknowledge the

difference of opinion and allow the process to move forward by
clarifying 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.

 

[AS] Yes. I agree with this.

 

If so, then why do you think "c" needs to change at all due

to its use in e via a type parameter?

 

[AS] As I said before, I have absolutely no problem with classes
declared in packages from

being extended in any other scope. I have already stated this.

 

Certainly one has to be careful about "e" since its

static "y" is module instance dependent, but we have

that problem in any case.

 

[AS] Yes. It is the _cross-module_ extension of class parameters that is
problematic. And you make

That same point below. You do recognize that access to "y" requires a
very different mechanism 

to access such static variables - and that mechanism has an additional
cost. The more general 

solution to this problem is normalize access to static variables and
treat all static's the same way.

As I wrote, this is not a fundamental problem, but one of additional
complexity and performance.

 

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.

 

[AS] Yes. And, those mimicking functions have a cost.

 

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.

 

[AS] I agree it is not fundamental - I have stated so several times.

 

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.