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

FYI, 1809 was just added to draft 7.

> -----Original Message-----
> From: Vreugdenhil, Gordon
> Sent: Friday, September 05, 2008 7:52 AM
> To: Bresticker, Shalom
> Cc: Daniel Mlynek; Arturo Salz; Rich, Dave; sv-bc@server.eda-stds.org;
> Mirek Forczek; Piotr Winter; Sergei Zaychenko
> Subject: Re: [sv-bc] declaration vs reference order issue
> 
> 
> 
> Bresticker, Shalom wrote:
> > Case 1 is clearly illegal.
> >
> > Cases 2 and 3 relate to situations where an identifier is
referenced,
> > there is a preceding declaration in an outer scope, and there is a
later
> > declaration in the same scope as the reference. The LRM is not clear
> > about this situation, and it was discussed in Mantis 1268, but not
> > resolved.
> >
> > What I have seen implemented in tools is to reference the outer
> > declaration until the point of the inner declaration and to
reference
> > from there on the inner declaration, but this has indeed not been
> > explicitly specified yet.
> 
> 
> 
>  From 1809:
> 
>     For a reference to an identifier other than function or task call,
>     the locally visible identifiers defined at the point of the
reference
>     in the current scope shall be searched. ...
> 
>     If no locally visible identifiers match, then the potentially
locally
>     visible identifiers defined prior to the point of the reference in
the
>     current scope shall be searched. ...
> 
>     If the reference is not found within the current scope, the next
outer
>     lexical scope shall be searched; ...
> 
> The rules here are clearly based from "the point of reference" in the
> first part.  Certainly that was the intent of all of the rules and
> all the special case rules for task and function "forward" resolution.
> 
> The $unit rules in 1809 are also in sync:
>     Next, the portion of the compilation-unit scope defined prior to
the
>     reference is searched
> 
> So I think that 1809 makes cases 2 & 3 pretty clear -- the outer "i"
is in
> fact the one that is used.  The meaning of a (non-task/function)
reference
> can change in the middle of a nested scope as they would in Daniel's
> examples.
> 
> Gord.
> 
> 
> 
> 
> > Regards,
> > Shalom
> >
> >
--------------------------------------------------------------------
> ----
> >     *From:* owner-sv-bc@server.eda.org
> >     [mailto:owner-sv-bc@server.eda.org] *On Behalf Of *Daniel Mlynek
> >     *Sent:* Friday, September 05, 2008 10:36 AM
> >     *To:* 'Arturo Salz'; 'Rich, Dave'; sv-bc@server.eda-stds.org
> >     *Cc:* 'Mirek Forczek'; 'Piotr Winter'; 'Sergei Zaychenko'
> >     *Subject:* RE: [sv-bc] declaration vs reference order issue
> >
> >     THX for responce.
> >     I'm getting used to that I get contradictory anwsers from each
> >     vendor specialist;) Maybe this is also feature which need to be
> >     explicitly addressed - as both of you cannot point LRM text
> >     resolvinf the issue. If I can I would choose Arturo's point of
view
> >     is more in this case. But I've additional question:
> >     case 1 - so for modules the rule : "A variable declaration shall
> >     precede any simple reference (non-hierarchical) to that
variable. "
> >     is broken in below code - and it should return compiler error?
> >     module top;
> >      initial $display(i);
> >      int i=123;
> >     endmodule
> >     case2; In below cases classes search rules that local identifier
> >     always take precedence  should not work and the results should
be
> 123
> >     *)
> >     module top;
> >      int i=123;
> >      module nest;
> >       initial $display(i);
> >       int i=456;
> >      endmodule
> >     endmodule
> >     **)
> >     module top;
> >      int i=123;
> >      function automatic f;
> >       int j=i;
> >       int i=456;
> >       $display(j);
> >      endfunction
> >
> >      initial f();
> >     endmodule
> >
> >     If so then this should surely be described - because this all is
far
> >     from obvious.
> >
> >     DANiel
> >
> >
---------------------------------------------------------------------
> > Intel Israel (74) Limited
> >
> > This e-mail and any attachments may contain confidential material
for
> > the sole use of the intended recipient(s). Any review or
distribution
> > by others is strictly prohibited. If you are not the intended
> > recipient, please contact the sender and delete all copies.
> >
> >
> > --
> > 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.