RE: [sv-bc] declaration vs reference order issue

From: Rich, Dave <Dave_Rich_at_.....>
Date: Fri Sep 05 2008 - 11:18:33 PDT
I would agree with making it an error in that case. I certainly don't
think people want different name resolution rules for inside classes
than outside classes, just like we don't want different expression
semantics inside classes or outside. This is true even if there is a
chance to correct something we don't like in Verilog.

Dave




> -----Original Message-----
> From: Arturo Salz [mailto:Arturo.Salz@synopsys.com]
> Sent: Friday, September 05, 2008 10:49 AM
> To: Vreugdenhil, Gordon; Arturo Salz
> Cc: Rich, Dave; Daniel Mlynek; sv-bc@eda-stds.org; Mirek Forczek;
Piotr
> Winter; Sergei Zaychenko
> Subject: RE: [sv-bc] declaration vs reference order issue
> 
> Gord,
> 
> As I replied in my previous message, binding the same identifier in a
> particular scope to more than one object is simply creating a debug
> problem for users. This is what I meant by "the only consistent way" -
> short of an error. Binding a name to multiple objects is (at least by
my
> definition) inconsistent. The problem exists in modules, but we have a
> chance to avoid the problem in classes - just as C++ has managed to
do.
> I am arguing from a user's perspective, not in favor of a particular
> implementation.
> 
> And I would definitely favor making your example an error - why would
> any user want to subject themselves to the problems associated with
> type/data aliases?
> 
> 	Arturo
> 
> -----Original Message-----
> From: Gordon Vreugdenhil [mailto:gordonv@model.com]
> Sent: Friday, September 05, 2008 8:06 AM
> To: Arturo Salz
> Cc: Rich, Dave; Daniel Mlynek; sv-bc@eda-stds.org; Mirek Forczek;
Piotr
> Winter; Sergei Zaychenko
> Subject: Re: [sv-bc] declaration vs reference order issue
> 
> Arturo,
> 
> I don't agree that this is "the only consistent way".  What is not
> consistent about claiming that the 1809 rules apply to classes
> from "the point of reference" in the same way?  Clearly the
> inherited names are "visible" prior to that point since the
> point of reference must follow any "extends" clause so that is
> a pretty easy interpretation.
> 
> I think that allowing the C++ style rules adds substantial
> complexity -- you now have different rules for type and non-type
> names since (I think) that everyone agrees that forward references
> to type names in a class can't be permitted.
> 
> So then you have to add yet more rules to deal with "changes of
> meaning" as you have in C++.  For example, the following is
> not legal in C++:
> 
>    typedef int myint;
>    class C {
>      myint x;
>      int myint;
>    };
> 
> 
> If you make this illegal in SV, you then have very different
> rules for class lexical visibility than for modules, etc.
> Why should forward ident references in classes be different than
> in modules, etc?
> 
> The name resolution rules in SV are already horrendous -- the
> interaction of dotted names, opaque types, hierarchical
> referencing, compilation unit, and legacy "forward" tf naming,
> make understanding things very, very difficult.
> 
> There is very little advantage to going to the C++ implicit
> forward naming.  You can already always get a forward data
> member reference by adding "this.", it is irregular with other
> nested scopes to have special rules, type references
> become even more irregular, and it is pretty easy to
> avoid the whole issue by coding conventions (data first).
> 
> Although I understand the appeal of following C++ in terms of
> what (some) users might expect, I just don't think that the
> resulting language issues justify it.
> 
> Gord
> 
> 
> Arturo Salz wrote:
> > Dave,
> >
> >
> >
> > This has been discussed in the past - in the context of
randomize-with
> 
> > and package imports. The only consistent way to deal with the 2
cases
> > that Daniel shows is to resolve all class references to the class,
> that
> > is, in the two examples, an undecorated 'i' always refers to the one
> > inside the class - both cases should display 2. This is similar to
the
> 
> > way in which C++ handles class members: undecorated references to
> class
> > members always resolve within the class, regardless of the
declaration
> 
> > order. And, like SV, C++ also has a declaration-before use rule for
> > other identifiers. BTW, don't forget that resolving names in classes
> > must also consider the inheritance hierarchy, for example:
> >
> >
> >
> > int v = 1;
> >
> >
> >
> > class B;
> >
> >   static int v = 2;
> >
> > endclass
> >
> >
> >
> > class C extends B;
> >
> >   static int w = v;            // this 'v' resolves to the base
class
> > B::v (2)
> >
> > endclass
> >
> >
> >
> > On another note, whether the compiler is a single-pass or
> multiple-pass
> > is definitely an implementation issue that should not be mandated by
> the
> > LRM. I recall that Mark Hartoog had proposed a scheme that would
> support
> > all this, but I don't see it in the text.
> >
> >
> >
> >             Arturo
> >
> >
> >
> > *From:* owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] *On Behalf
Of
> 
> > *Rich, Dave
> > *Sent:* Thursday, September 04, 2008 8:49 AM
> > *To:* Daniel Mlynek; sv-bc@eda-stds.org
> > *Cc:* Mirek Forczek; Piotr Winter; Sergei Zaychenko
> > *Subject:* RE: [sv-bc] declaration vs reference order issue
> >
> >
> >
> > Mantis 2106 added to 6.21
> >
> >
> >
> > A variable declaration shall precede any simple reference
> > (non-hierarchical) to that variable.
> >
> >
> >
> > So there can be no tool dependence on this issue. Customers
certainly
> do
> > not like when code compiles on one simulator and not on another. The
> > begrudgingly accept order of evaluation dependencies only if a
single
> > implementation cannot guarantee ordering.
> >
> >
> >
> > For case 2, I thought we had added text that defines the search
rules
> > from the point of the source code, but I can't seem to find it. But
> > given the rule above, there's no way $display(i) can refer to this.i
> and
> > display 2.
> >
> >
> >
> > Dave
> >
> >
> >
> >
> >
> >
> >
> >
>
------------------------------------------------------------------------
> >
> > *From:* owner-sv-bc@server.eda.org
[mailto:owner-sv-bc@server.eda.org]
> 
> > *On Behalf Of *Daniel Mlynek
> > *Sent:* Thursday, September 04, 2008 2:53 AM
> > *To:* sv-bc@server.eda-stds.org
> > *Cc:* 'Mirek Forczek'; 'Piotr Winter'; 'Sergei Zaychenko'
> > *Subject:* [sv-bc] declaration vs reference order issue
> >
> >
> >
> > CASE1:
> >
> > Does LRM defines rules on how tool should behave if reference to
> > an identifier which is unknown at this point of source code.
> Idetnifier
> > is delcared later in code (case1). LRM specifies that both single
pass
> 
> > parser and multi pass parser may be used for parsing SV code (LRM:"
> > Implementations may execute compilation in one or more passes") It
is
> > obvious that single pass compiler will fail on case like below,
while
> > mutli pass can handle with that. So this should be tool dependend if
> > CASE would pass compilation?
> >
> >
> >
> > 2nd case is connected - what should happend if in current scope and
in
> 
> > higher scope there is an identifier declared. But in current scope
> > declaration is place in code after reference - so which one should
be
> > printed by case2. Is it defined or tool dependend?
> >
> >
> >
> > LRM:22.9 says:"If an identifier is referenced directly (without a
> > hierarchical path) within a task, function, named block, or generate
> > block, it shall be declared either within the task, function, named
> > block, or generate block locally or within a module, interface,
> program,
> > task, function, named block, or generate block that is higher in the
> > same branch of the name tree that contains the task, function, named
> > block, or generate block. If it is declared locally, then the local
> item
> > shall be used; if not, the search shall continue upward until an
item
> by
> > that name is found or until a module,  interface, or program
boundary
> is
> > encountered."
> >
> > So imho in both cases "2" should be displayed
> >
> >
> >
> >
> >
> >
> >
> > CASE1:
> >
> > module top;
> >
> >
> >
> >    class nested;
> >        function new ();
> >               $display(i);    //  displaying "i" - this should be a
> > failure - as i is unkcnown since here, or 2 shoudl be displayed?
> >       endfunction
> >       int i = 2;               // local member "i"
> >    endclass
> >
> >
> >
> >    nested n_inst = new();
> >
> >
> >
> > endmodule
> >
> >
> >
> > CASE2:
> >
> > module top;
> >     bit [2:0] i = 0;   // static member "i"
> >
> >
> >
> >    class nested;
> >        function new ();
> >               $display(i);    //  displaying "i" - which i would be
> > displayed - ???????????????
> >       endfunction
> >       int i = 2;               // local member "i"
> >    endclass
> >
> >
> >
> >    nested n_inst = new();
> >
> >
> >
> > endmodule
> >
> >
> >
> >
> >
> >
> >
> > DANiel
> >
> >
> > --
> > This message has been scanned for viruses and
> > dangerous content by *MailScanner* <http://www.mailscanner.info/>,
and
> is
> > believed to be clean.
> > --
> > This message has been scanned for viruses and
> > dangerous content by *MailScanner* <http://www.mailscanner.info/>,
and
> is
> > believed to be clean.
> >
> >
> > --
> > This message has been scanned for viruses and
> > dangerous content by *MailScanner* <http://www.mailscanner.info/>,
and
> is
> > believed to be clean.
> 
> --
> --------------------------------------------------------------------
> 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.
Received on Fri Sep 5 11:19:20 2008

This archive was generated by hypermail 2.1.8 : Fri Sep 05 2008 - 11:19:32 PDT