RE: [sv-ec] "this" and member resolution in inline constraints

From: Arturo Salz <Arturo.Salz_at_.....>
Date: Wed Dec 19 2007 - 10:04:16 PST
Gordon Vreugdenhil wrote:

> 

> Mark Hartoog wrote:

> > I am confused by what the issue is here.

> 

> It is clarity of the text for the non-implementor.

> 

> > Compile time resolution is always in terms of the statically
declared

> > fields and methods. Some methods may be declared virtual in the
static

> > class.

>  > This means that at compile time you resolve to the virtual

> > method.

> > All type checking is done against the virtual method. The actual
method

> > that is called is selected at run time. Data field members are never

> > virtual.

> >

> > In your example the 'x' in the randomize with block resolves to the
int

> > 'x' in

> > class 'C'.

> 

> 

> Sure, you and I and other implementors know that.  I'm certainly

> not suggesting any other binding.

> 

> 

> What the text doesn't say is:

>    1) that the inline constraint is effectively its own non-virtual

>       method rather than being "part of" randomize.  Without

>       such a statement the only "this" that a reader could assume is

>       the "this" of the randomize method that is *actually called*.

>       That type is not known.

>    2) that the class in which the "method" lives is the class

>       defined by the type of the reference

> 

 

That language is not the clearest explanation (i.e., what does "lives"
mean).

Obviously, an inline constraint is unique and we run into problems when
trying to define it in terms of other constructs. I think we should only
attempt to state its semantics unambiguously.

 

> The current approved 1858 text talks about "the randomize...with
object"

> and NOT the type of the reference.  That could easily lead readers

> to assume the highly dynamic behavior.

> 

 

Actually, the text talks about "the randomize...with object class" and
that language can certainly be made more explicit to mean the class of
the object used in the call to randomize (the static type or the type of
the reference). That has always been the intent of that verbiage.  The
LRM and the approved proposal do not include language that mention the
randomize method for name binding - that issue was raised by Ray who
pointed out that "this" is not part of the object scope but is available
only in non-static methods.

 

> By the way, you certainly cannot tell the type of the class reference

> at compile time -- if the prefix is a general hierarchical reference

> or similar then you can't possibly know until elaboration time.  So

> where the names bind is certainly an elaboration time decision

> based on the static type of the reference; the non-virtual method

> model is just a convenient way to talk about the effect.

> 

 

True, but that is not unique to in-line constraints. The type of any
hierarchical reference is not known at parse time and needs to be
resolved after elaboration. I believe by compile time Mark meant to
include elaboration, in much the same way as the LRM distinguishes only
compile-time and run-time.

 

> Gord.

> 

 

Since at this point, we seem to agree on what the rules are (please
correctly if that is not the case), shouldn't we concentrate on the
verbiage that removes any potential ambiguity. I propose the following:

 

The scope for resolution of variable names referenced in the in a
constraint block begins with the randomize()...with object class, i.e.,
the class of the object used in the call to randomize. If a name fails
to resolve within the randomize()...with object class, the name is
resolved normally starting in the scope containing the inline
constraint.

 

If this is acceptable, I'll incorporate it into the proposal. Otherwise,
would you please suggest a better alternative.

 

      Arturo

 

 

> >

> >

> > -----Original Message-----

> > From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of

> > Gordon Vreugdenhil

> > Sent: Tuesday, December 18, 2007 1:50 PM

> > To: SV_EC List

> > Subject: [sv-ec] "this" and member resolution in inline constraints

> >

> >

> > In considering some of the wording for the 1858 (inline constraints
name

> > resolution) issues, I would like to raise an additional concern
and/or

> > need for clarification.

> >

> > "randomize" is definitely a virtual method.  In the discussion, we
were

> > talking about "this" as following the normal method resolution rules
for

> > "this" references.  That does pose a problem when everything is

> > composed.

> >

> > Consider this case:

> >

> >            class C;

> >               rand int x;

> >            endclass

> >            class D extends C;

> >               rand bit[1:0] x;

> >            endclass

> >            D d = new;

> >            C c = d;

> >

> >            initial c.randomize with { x > 0 && x < 10; };

> >

> > My working assumption has always been that the resolution of "x" is

> > based on the static type of the object prefix, but I think that the

> > wording and discussion related to "this" has at least muddied the
waters

> > if not compromised that interpretation completely.

> >

> > If I have:

> >           initial c.randomize with { this.x > 0 && this.x < 10; };
the

> > meaning of "this" is now different.  We would have to interpret
"this"

> > not as the formal of the virtual method "randomize"

> > but as "a reference to the portion of the object addressable by the

> > static type of c".

> >

> > There are many, many issues with a dynamic interpretation of "this"
so I

> > would not want to propose that we follow the dynamic resolution
path.  I

> > believe that the statically typed interpretation I have above is

> > consistent with Arturo's view.

> >

> > Since "this" would not follow the normal semantics of a virtual
method,

> > I think that this needs to be reexamined or clarified as part of
1858.

> >

> > If the more static view of name binding is followed, there are still

> > potential questions related to handling of other virtual method

> > references within a constraint and the overall coherency of object

> > assumptions in such cases.

> >

> > Gord.

> > --

> > --------------------------------------------------------------------

> > Gordon Vreugdenhil                                503-685-0808

> > Model Technology (Mentor Graphics)                gordonv@model.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.
Received on Wed Dec 19 10:05:02 2007

This archive was generated by hypermail 2.1.8 : Wed Dec 19 2007 - 10:05:32 PST