Re: [sv-ec] Re: [sv-bc] Slides for name resolution face to face

Jonathan Bromley wrote:
>> Upward searches are only for the starting point of a path,
>> never within them.
> 
> I'm immensely relieved to hear Steven say that.  It had
> never crossed my mind that it might be otherwise, but some
> of the recent discussions had caused me to question it.
> 
> That still leaves the question of whether it's OK to
> backtrack - having found a candidate starting point for
> the name search by floating up the hierarchy, are you 
> prepared to try again (continuing to float upwards and then
> Redo From Start on finding another, ancestor candidate) if
> the remainder of the name is not a valid downward path
> from your candidate starting point?  Again, I've never
> been 100% clear about that.

Steven's characterization of my concerns was correct.

In general, I am not worried about any pure downwards
resolution.  By saying that you never "go back to
a hierarchical search" my intent was to say that you
don't ever try another alternative; you are committed
to that downward path.  Certainly for virtual interfaces,
it is clear that we need to allow resolution into scopes
referenced by the virtual interface.

On slide 24, the statement:
    Intent: Once we start with a “selected” name, we never revert
    to a hierarchical resolution.
Is better expressed as:
    Intent: Once we start with a “selected” name, we commit to
    that downward path; no further upwards resolution occurs.


This was actually one point where we weren't in consensus
on things in the face to face.  Matt expressed a preference
to have the upwards search continue even on a struct mismatch.
This would ONLY apply if we were in the upwards phase of the
resolution.

The rules that Matt wants are, I think:
   1) when we are not in the upwards instance phase, if
      we get to a "select dot" then we are committed to
      that downward path
   2) once we have gone to an upwards instance, you always
      keep trying upwards even if a downwards attempt encounters
      a struct.

I am not entirely comfortable with those rules.  If the rule
of "once you get to a select dot you commit to that downward
path"  produces an error and the Matt's rules do not, it means
that there was a "closer" struct that didn't match the path.
It seems more likely to me that this would be a user error
rather than the intent of the user.

Matt's approach would also be philosophically different that
what Steven and I both believe is correct for arrayed instances
and generate loops -- if an index is out of bounds on the
nearest loop, it is an error, you don't keep looking for
arrays further up that might match.

Matt, I don't recall whether you ended up reluctantly
agreeing to the approach that I was suggesting or whether
you still want to champion the "try again" rules.  Can
you comment on where you are on this point?

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.