RE: [sv-ec] calls to constructor after "begin"

Gord,

I share your concerns about reachability analysis. That is precisely why
the LRM was written using the current "looser" language.

BTW, the LRM still leaves much ambiguity as to what is allowed. I agree
that as written, Jonathan's case 2 would be non-compliant. But a simple
re-write would make it compliant (if not in spirit or intent), for
example:
     function new(int A);
        super.new( f(A) );
     endfunction	

Similarly, the branching code can be written as:
   function new(int A);
       super.new( (A != 0) ? A : -1 );
   endfunction

I do believe that a tightening along the lines you propose would be a
good enhancement. A typical problem is calling virtual methods from
within constructors, which can result in surprising results, often
crashing the application. The challenge is to devise a set of rules that
are well defined, self-contained, and simple enough for users to
remember and apply.

	Arturo

-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
Gordon Vreugdenhil
Sent: Tuesday, January 02, 2007 7:27 AM
To: SV_EC List
Subject: RE: [sv-ec] calls to constructor after "begin"


Sorry for the form of the response -- reflector issues.  I think
things are working now but they weren't on the 27th yet.
----


Jonathan,

I would consider your case 1 to be illegal.  It is clearly not
compliant with the LRM requirements and would require a "reachability"
analysis that the LRM typically does not require.  For example,
if you had:
     if (P) super.new(A);
for a parameter P and P's elaborated value was never 0 then would this
be legal?  If so, the "reachability" needs to validated at
elaboration time and such code wouldn't produce any compile
errors.

If we want to embed a more sophisticated reachability analysis
requirement in the LRM then we'll have to be very, very careful
about what is permitted and when errors will then be reportable.
Deferring such errors into elab time might not be in the user's
interest.


For case 2, there are a bunch of related issues.  For example,
if you had:
     function new(int A);
        int y = f(A);
        super.new(y);
     endfunction
This satisfies the formal requirement of the LRM but likely
does not satisfy either the intent nor the actual "safety"
of the method.


I think we could go a couple of ways on this.  The easiest
is to disallow class method calls in variable initial values
within "new".  Combining this with the existing requirements
would allow a reasonable level of flexibility.  We could
also then allow non-branching/conditional code without
method calls to precede the super.new call (which is equivalent
to the initialization calls).

Gord.

----


From: Jonathan Bromley <jonathan.bromley_at_.....>
Date: Wed Dec 27 2006 - 08:25:16 PST

 > The constraint really should be (in imprecise language)
 > that the first statement other than a scope entry "begin"
 > must be the super.new call.

Just a small side-issue...  Suppose we have a super.new
that expects one int argument, how about these two cases?

case 1: conditional call
~~~~~~~~~~~~~~~~~~~~~~~~

function new(int A);
   if (A!=0)
     super.new(A);
   else
     super.new(-1);
...

case 2: call with function or expression in arguments
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

function new (int A);
   super.new(A-1);
   // or even...
   // super.new(some_function(A));

At least one simulator let me get away with case 1 the
last time I tried it.  I haven't checked case 2.
Clearly it involves something being executed before
super.new, and yet it looks fairly sensible (especially
if some_function is a static method of the class).
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24
1AW, UK
Tel: +44 (0)1425 471223                   Email:
jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573                           Web:
http://www.doulos.com
-- 
--------------------------------------------------------------------
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.