RE: [sv-bc] Re: [sv-ec] task/function actuals for mode "ref"

<forwarding bounced email from Vreugdenhil, Gordon>


-------- Original Message --------
Subject: RE: [sv-bc] Re: [sv-ec] task/function actuals for mode "ref"
Date: Wed, 16 Jan 2008 19:39:20 -0800
From: "Vreugdenhil, Gordon" <gordon_vreugdenhil@mentor.com>
To: "Arturo Salz" <Arturo.Salz@synopsys.com>,
         "Steven Sharp" <sharp@cadence.com>
Cc: <Neil.Korpusik@sun.com>, <shalom.bresticker@intel.com>,
         <sv-bc@server.eda.org>, <sv-ec@server.eda.org>


I certainly agree that since consts, parameters,
literals, etc. are not lvals, they aren't allowed
for normal ref formals.

But there is a related sub-question on that.  Since
a "const ref" is not an lval, I have been assuming
that a "const" variable (at least) is a valid actual for=20
a const ref.  I think that I'd be prepared to allow
a parameter or localparam as well.  Literals, concats,
etc. I'd probably want to leave off although I could
be convinced otherwise.


Gord.


-----Original Message-----
From: Arturo Salz [mailto:Arturo.Salz@synopsys.com]
Sent: Wed 1/16/2008 6:05 PM
To: Vreugdenhil, Gordon; Steven Sharp
Cc: Neil.Korpusik@sun.com; shalom.bresticker@intel.com; sv-bc@eda.org; sv-e=
c@eda.org
Subject: RE: [sv-bc] Re: [sv-ec] task/function actuals for mode "ref"
=20
It probably wouldn't hurt to add that constants are also disallowed as
ref arguments.

	Arturo

-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
Gordon Vreugdenhil
Sent: Wednesday, January 16, 2008 3:54 PM
To: Steven Sharp
Cc: Neil.Korpusik@sun.com; shalom.bresticker@intel.com; sv-bc@eda.org;
sv-ec@eda.org
Subject: Re: [sv-bc] Re: [sv-ec] task/function actuals for mode "ref"



Steven Sharp wrote:
> The proposal looks reasonable to me.
>=20
> The phrase "a member select of a class property" might be
misinterpreted
> as meaning that you apply a member select to a class property.  I
assume
> that the intent was a member select whose result is a class property
(i.e.
> not a class method).  It might be better to just say "a class
property"
> instead of "a member select of a class property."=20=20

Sigh.  I probably need to just generalize this all properly since
"a class property" has the same issues as "a variable".  The real
restriction is a recursive definition involving variables,
properties, selects and types.  It is really ugly to write that
down in precise terms without it becoming a huge definition.

  >  Note also that it is
> OK to pass a class property from inside the class, without using an
> explicit member select to access it (though you could argue that it is
> an implicit member select via 'this').  As far as I can see, if there
is
> any way to reference a class property besides a member select, it is
still
> OK to pass it.

Yup.  See my above comments.  Even if you have:
     some_property.some_field_of_type_class.some_other_property
it is still Ok.  The entire definition is recursive on
the fundamental issues -- you can't end up picking off "part of"
a packed thing.



I am very busy right now on multiple fronts.  I'm not going
to try to rewrite this unless we're sure that we can get this
into the 2008 spec yet.

Gord.
--=20
--------------------------------------------------------------------
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.