RE: [sv-ec] sub-class constructor

Thomas,

I think you have to accept that new() is a special method that cannot be
overridden. You must call the constructors in an orderly chain to
properly allocate and initialize the state of class members. What would
happen to the state of local variables if you were allowed to override
its constructor? 

The OVM in fact delegates most of what is normally considered the chore
of the constructor to a separate build() method so that it can be
completely overridden in subsequent extended classes.

Allowing the call to super.new() to be something other than the first
statement is non-trivial. I think the rules for which statements would
be allowed and what variables they could access would be quite complex.
Ultimately, it is easer to express what's needed as an expression
argument in the call to super.new().

Dave


-----Original Message-----
From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org] On
Behalf Of Alsop, Thomas R
Sent: Thursday, February 12, 2009 8:56 AM
To: Vreugdenhil, Gordon; Jonathan Bromley
Cc: Bresticker, Shalom; sv-ec@server.eda.org; Feldman, Yulik
Subject: RE: [sv-ec] sub-class constructor

Hi Gord,

I didn't quite understand the two examples you gave below. Are you
basically saying the C++ infers arguments passed in super.new() child
calls and that SV is not clear on this?

I can appreciate the Doulos documentation given the shortcomings in the
SV LRM.  Wasn't sure if this was given as SV gospel or methodology.
Seems like it should be a methodology statement.  I believe the VMM has
this as a 'Rule' or 'Guideline', i.e. always call super.new(), with
arguments if needed, when child constructors are defined.  

The virtual aspect comes into play depending on the usage model, right?
If you want your base classes constructors to be 'overriden' (i.e.
polymorphism) but still include the super.new() functionality, then your
child new() definition would call super.new().  If you want to
completely change what all the extended classes do up to the base, then
the child new() definition would not call super.new(), right?

In the case of non-virtual child new() calls, again, calling super.new()
really depends on whether the end user want to completely override the
super.new() or not.  Although it doesn't sound like good practice, this
may be something they want or need in the extended class.  

Seems to me that we shouldn't define the SV LRM to implicitly call
super.new() in child extensions, rather we should state that this will
not be the case and let the methodologies that are out there recommend
this practice.

Thanks, -Tom

-----Original Message-----
From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org] On
Behalf Of Gordon Vreugdenhil
Sent: Thursday, February 12, 2009 8:18 AM
To: jonathan.bromley@doulos.com
Cc: Bresticker, Shalom; sv-ec@server.eda.org; Feldman, Yulik
Subject: Re: [sv-ec] sub-class constructor



jonathan.bromley@doulos.com wrote:
> Shalom,
> 
[...]

> For my part, I'll take an action to get that cleaned-up in
> our GRG.  However, the SV LRM could perhaps be a little
> more helpful than it is in clarifying this behaviour. There
> are some corner cases that don't seem to me to be too 
> clear.  In particular, any attempt to compute the arguments
> to super.new() will seriously muddy the waters:
> 
>   class C;
>     function new(int x);
>     ...
>   endclass : C
>  
>   class D extends C;
>     function new(bit b);
>       if (b)
>         super.new(-1);
>       else
>         super.new(1);
>    ...
> 
> Is that legal?  

No, it isn't.

> If not, could it be made legal thus?
> 
>    function D::new(bit b);
>      super.new(b? -1: 1);

Yes.

> Would it be legal to call a function to compute
> the arguments? (Evidently, not a *member* function.)

Argument evaluation is an expression evaluation; any such
evaluation is fine.  Member functions are not in fact
disallowed by the LRM although the semantics of such
calls are ill-defined.  For example, C++ is very clear
that the effective vtbl (set of virtual method bindings)
follows the "current" type of the base class constructor
during construction.  SV is not at all clear on this and
users would be well advised to not rely on the semantics
of such calls.

Example:

module top;
    class C;
       virtual function int f();
          return 1;
       endfunction
       int x = f();            // ill-defined in SV
    endclass
    class D extends C;
       function int f();
          return 2;
       endfunction
       int y = f();            // ill-defined in SV
    endclass

    D d = new;
    initial $display(d.x,,d.y);
endmodule


C++ equivalent:

#include <iostream>
class foo {
   public:
     virtual int f() { return 1; }
     int x;
     foo() { x = f(); }   // C++ compliant call to foo::f even
                          // during derived object construction
};

class bar : public foo {
   public:
     virtual int f() { return 2; }
     int y;
     bar() { y = f(); }   // C++ compliant call to bar::f
};


main()
{
    bar *b = new bar;
    std::cout << b->x << "   " << b->y << std::endl;
}



> In all such cases, super.new() is not the first
> executable code in D::new() even if it is
> lexically the first code to appear.

That is true and one could spoof all sorts of bad behavior
by creating a dummy property and using a function call
to evaluate.  Suggestion -- don't do that; it will likely
hurt.

Other than for rather simple, definitely "local" value
construction, I would be careful about making assumptions
about ordering and if you want to be very careful, do
the initialization explicitly in the constructor chain,
rather than using initializers.  Finally, as indicated
above, I would not rely on any virtual method calls in SV
constructors at this point since the semantics are not
explicitly defined.

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.


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



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