[sv-ec] from ["Vreugdenhil, Gordon" <gordon_vreugdenhil@mentor.com>]

From: Mehdi Mohtashemi <Mehdi.Mohtashemi_at_.....>
Date: Sun May 03 2009 - 12:03:40 PDT
-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org]
Sent: Sunday, May 03, 2009 11:59 AM
To: sv-ec-approval@eda.org
From: "Vreugdenhil, Gordon" <gordon_vreugdenhil@mentor.com>
To: "Arturo Salz" <Arturo.Salz@synopsys.com>,
        "Surya Pratik Saha" <spsaha@cal.interrasystems.com>
Cc: "Alok Kumar Sinha" <aksinha@cal.interrasystems.com>,
        <sv-bc@server.eda.org>, <sv-ec@server.eda.org>



Arturo, the C#(2)::p is referring to the parameter "p" of
the specialization, not the "int p;" in the task.  Parameters
are considered equivalent to "static" in terms of referencing,
so there shouldn't be any issue here.  Did you misread the
example a bit or do you not view parameters as static?

Gord.


-----Original Message-----
From: Arturo Salz [mailto:Arturo.Salz@synopsys.com]
Sent: Sun 5/3/2009 10:58 AM
To: Surya Pratik Saha; Vreugdenhil, Gordon
Cc: Alok Kumar Sinha; sv-bc@eda.org; sv-ec@eda.org
Subject: RE: [sv-bc] Issues regarding default specialization of class
=20
Surya,

A different specialization within the class legal. Your example is not lega=
l because "p" is not static hence the expression "C#(2)::p" is not legal in=
 other contexts, but, if it were static, it would be legal.

        Arturo

-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Surya P=
ratik Saha
Sent: Saturday, May 02, 2009 10:41 PM
To: Gordon Vreugdenhil
Cc: Alok Kumar Sinha; sv-bc@eda.org; sv-ec@eda.org
Subject: Re: [sv-bc] Issues regarding default specialization of class

Hi Gord,
One related question. Can we use specialization of class inside that
class declaration? Is the below mentioned e.g. valid?

class C #(int p =3D 1);
static task t;
int p;
int x =3D C #(2) ::p; // Is it illegal or legal ?
endtask
endclass

I am not clear from the LRM text.

Regards
Surya



-------- Original Message  --------
Subject: Re:[sv-bc] Issues regarding default specialization of class
From: Gordon Vreugdenhil <gordonv@model.com>
To: Alok Kumar Sinha <aksinha@cal.interrasystems.com>
Cc: sv-bc@eda.org, sv-ec@eda.org
Date: Wednesday, April 29, 2009 7:38:07 PM
> See below.
>
>
> Alok Kumar Sinha wrote:
>> Hi,
>>
>> I have two issues regarding default specialization of class:
>>
>> 1) According to LRM P1800-2009-draft7a, section 8.24.1,
>>
>> "In the context of a parameterized class method out-of-block
>> declaration, use of the class scope resolution
>> operator shall be a reference to the name as though it was made
>> inside the parameterized class; no specialization
>> is implied."
>>
>> Now for the example :
>>
>> class C #(int p =3D 1, type T =3D int);
>>    extern static function T f();
>> endclass
>> function C::T C::f();
>>    return p + C::p;
>> endfunction
>>
>> So, for the return type of function 'f',  any specialization is not
>> required as the function is itself a method of that class
>> and is only declared outside.
>>
>> But one of the standard simulaters which supports this type of
>> semantic check, is failing on the csae and is expecting
>> a specialization for return type too.
>> Am I missing something or is it a simulater bug.
>
>
>
> The above kind of example was not clearly defined in the LRM
> for 2005 and the text you are quoting came in rather late
> in the 2009 process.  This is certainly a "bug" but a very
> understandable one in that it does take time for implementations
> to reflect late changes (particularly since this is still just
> in balloting!).
>
>
>
>
>> Here I also want to raise an implementation issue.
>>
>> If the function is defined as :
>> function C::T f();
>>    return p + C::p;
>> endfunction
>>
>> It is definitely an error as this function is not the method of the
>> class C.
>> But it is difficult to detect the error, because it is clear that any
>> error for C::T can only be detected
>> after function name is found during parsing. Is it the real intention
>> of the LRM?
>
>
> Yes, that is the intent.
>
> The reverse case is much worse -- if C::T implied the
> default specialization then you'd have no reasonable way to
> deal with the earlier case (unless you conceptually "undid"
> the specialization).
>
> Making the "C::T" have context dependent specialization
> semantics was deemed to be way too confusing -- many users
> already don't really understand default specialization
> and having C::T mean different things would not help.
>
>
>>
>> 2.  How can we decide for any specialization if any class is
>> forwardly declared.
>> For e.g. ,
>> module top;
>>    typedef     C;
>>    initial
>>        begin
>>            C:: x =3D 1;     // Is the specialization is required or it
>> is an error ?
>
>
> You cannot tell at this point.  You can only determine that this
> is an error once you see the actual class declaration.
>
>
>
>>        end
>>    class C #(parameter int p =3D 1, parameter type T =3D int );
>>        static T x;
>>    endclass
>> endmodule
>>
>> When C::x is declared we do not know whether C will a parameterized
>> class or not.
>>
>> The Mantis 1857 due to which the text added in the LRM is silent on
>> that.
>>
>> Please anyone give suggestion regarding this.
>
>
> I can't really give suggestions on your implementation; there
> are many implementation level details that impact how you
> decide to do this.  The basic approach would have to involve
> deferring the decision until later and "back patching" the
> actual use.
>
> Gord.




--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.



--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


------_=_NextPart_001_01C9CC21.01B6F7D1
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Diso-8859-=
1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version 6.5.7654.9">
<TITLE>RE: [sv-bc] Issues regarding default specialization of class</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<BR>

<P><FONT SIZE=3D2>Arturo, the C#(2)::p is referring to the parameter &quot;=
p&quot; of<BR>
the specialization, not the &quot;int p;&quot; in the task.&nbsp; Parameter=
s<BR>
are considered equivalent to &quot;static&quot; in terms of referencing,<BR>
so there shouldn't be any issue here.&nbsp; Did you misread the<BR>
example a bit or do you not view parameters as static?<BR>
<BR>
Gord.<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: Arturo Salz [<A HREF=3D"mailto:Arturo.Salz@synopsys.com">mailto:Artur=
o.Salz@synopsys.com</A>]<BR>
Sent: Sun 5/3/2009 10:58 AM<BR>
To: Surya Pratik Saha; Vreugdenhil, Gordon<BR>
Cc: Alok Kumar Sinha; sv-bc@eda.org; sv-ec@eda.org<BR>
Subject: RE: [sv-bc] Issues regarding default specialization of class<BR>
<BR>
Surya,<BR>
<BR>
A different specialization within the class legal. Your example is not lega=
l because &quot;p&quot; is not static hence the expression &quot;C#(2)::p&q=
uot; is not legal in other contexts, but, if it were static, it would be le=
gal.<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Arturo<BR>
<BR>
-----Original Message-----<BR>
From: owner-sv-bc@eda.org [<A HREF=3D"mailto:owner-sv-bc@eda.org">mailto:ow=
ner-sv-bc@eda.org</A>] On Behalf Of Surya Pratik Saha<BR>
Sent: Saturday, May 02, 2009 10:41 PM<BR>
To: Gordon Vreugdenhil<BR>
Cc: Alok Kumar Sinha; sv-bc@eda.org; sv-ec@eda.org<BR>
Subject: Re: [sv-bc] Issues regarding default specialization of class<BR>
<BR>
Hi Gord,<BR>
One related question. Can we use specialization of class inside that<BR>
class declaration? Is the below mentioned e.g. valid?<BR>
<BR>
class C #(int p =3D 1);<BR>
static task t;<BR>
int p;<BR>
int x =3D C #(2) ::p; // Is it illegal or legal ?<BR>
endtask<BR>
endclass<BR>
<BR>
I am not clear from the LRM text.<BR>
<BR>
Regards<BR>
Surya<BR>
<BR>
<BR>
<BR>
-------- Original Message&nbsp; --------<BR>
Subject: Re:[sv-bc] Issues regarding default specialization of class<BR>
From: Gordon Vreugdenhil &lt;gordonv@model.com&gt;<BR>
To: Alok Kumar Sinha &lt;aksinha@cal.interrasystems.com&gt;<BR>
Cc: sv-bc@eda.org, sv-ec@eda.org<BR>
Date: Wednesday, April 29, 2009 7:38:07 PM<BR>
&gt; See below.<BR>
&gt;<BR>
&gt;<BR>
&gt; Alok Kumar Sinha wrote:<BR>
&gt;&gt; Hi,<BR>
&gt;&gt;<BR>
&gt;&gt; I have two issues regarding default specialization of class:<BR>
&gt;&gt;<BR>
&gt;&gt; 1) According to LRM P1800-2009-draft7a, section 8.24.1,<BR>
&gt;&gt;<BR>
&gt;&gt; &quot;In the context of a parameterized class method out-of-block<=
BR>
&gt;&gt; declaration, use of the class scope resolution<BR>
&gt;&gt; operator shall be a reference to the name as though it was made<BR>
&gt;&gt; inside the parameterized class; no specialization<BR>
&gt;&gt; is implied.&quot;<BR>
&gt;&gt;<BR>
&gt;&gt; Now for the example :<BR>
&gt;&gt;<BR>
&gt;&gt; class C #(int p =3D 1, type T =3D int);<BR>
&gt;&gt;&nbsp;&nbsp;&nbsp; extern static function T f();<BR>
&gt;&gt; endclass<BR>
&gt;&gt; function C::T C::f();<BR>
&gt;&gt;&nbsp;&nbsp;&nbsp; return p + C::p;<BR>
&gt;&gt; endfunction<BR>
&gt;&gt;<BR>
&gt;&gt; So, for the return type of function 'f',&nbsp; any specialization =
is not<BR>
&gt;&gt; required as the function is itself a method of that class<BR>
&gt;&gt; and is only declared outside.<BR>
&gt;&gt;<BR>
&gt;&gt; But one of the standard simulaters which supports this type of<BR>
&gt;&gt; semantic check, is failing on the csae and is expecting<BR>
&gt;&gt; a specialization for return type too.<BR>
&gt;&gt; Am I missing something or is it a simulater bug.<BR>
&gt;<BR>
&gt;<BR>
&gt;<BR>
&gt; The above kind of example was not clearly defined in the LRM<BR>
&gt; for 2005 and the text you are quoting came in rather late<BR>
&gt; in the 2009 process.&nbsp; This is certainly a &quot;bug&quot; but a v=
ery<BR>
&gt; understandable one in that it does take time for implementations<BR>
&gt; to reflect late changes (particularly since this is still just<BR>
&gt; in balloting!).<BR>
&gt;<BR>
&gt;<BR>
&gt;<BR>
&gt;<BR>
&gt;&gt; Here I also want to raise an implementation issue.<BR>
&gt;&gt;<BR>
&gt;&gt; If the function is defined as :<BR>
&gt;&gt; function C::T f();<BR>
&gt;&gt;&nbsp;&nbsp;&nbsp; return p + C::p;<BR>
&gt;&gt; endfunction<BR>
&gt;&gt;<BR>
&gt;&gt; It is definitely an error as this function is not the method of th=
e<BR>
&gt;&gt; class C.<BR>
&gt;&gt; But it is difficult to detect the error, because it is clear that =
any<BR>
&gt;&gt; error for C::T can only be detected<BR>
&gt;&gt; after function name is found during parsing. Is it the real intent=
ion<BR>
&gt;&gt; of the LRM?<BR>
&gt;<BR>
&gt;<BR>
&gt; Yes, that is the intent.<BR>
&gt;<BR>
&gt; The reverse case is much worse -- if C::T implied the<BR>
&gt; default specialization then you'd have no reasonable way to<BR>
&gt; deal with the earlier case (unless you conceptually &quot;undid&quot;<=
BR>
&gt; the specialization).<BR>
&gt;<BR>
&gt; Making the &quot;C::T&quot; have context dependent specialization<BR>
&gt; semantics was deemed to be way too confusing -- many users<BR>
&gt; already don't really understand default specialization<BR>
&gt; and having C::T mean different things would not help.<BR>
&gt;<BR>
&gt;<BR>
&gt;&gt;<BR>
&gt;&gt; 2.&nbsp; How can we decide for any specialization if any class is<=
BR>
&gt;&gt; forwardly declared.<BR>
&gt;&gt; For e.g. ,<BR>
&gt;&gt; module top;<BR>
&gt;&gt;&nbsp;&nbsp;&nbsp; typedef&nbsp;&nbsp;&nbsp;&nbsp; C;<BR>
&gt;&gt;&nbsp;&nbsp;&nbsp; initial<BR>
&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; begin<BR>
&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
C:: x =3D 1;&nbsp;&nbsp;&nbsp;&nbsp; // Is the specialization is required o=
r it<BR>
&gt;&gt; is an error ?<BR>
&gt;<BR>
&gt;<BR>
&gt; You cannot tell at this point.&nbsp; You can only determine that this<=
BR>
&gt; is an error once you see the actual class declaration.<BR>
&gt;<BR>
&gt;<BR>
&gt;<BR>
&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; end<BR>
&gt;&gt;&nbsp;&nbsp;&nbsp; class C #(parameter int p =3D 1, parameter type =
T =3D int );<BR>
&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; static T x;<BR>
&gt;&gt;&nbsp;&nbsp;&nbsp; endclass<BR>
&gt;&gt; endmodule<BR>
&gt;&gt;<BR>
&gt;&gt; When C::x is declared we do not know whether C will a parameterize=
d<BR>
&gt;&gt; class or not.<BR>
&gt;&gt;<BR>
&gt;&gt; The Mantis 1857 due to which the text added in the LRM is silent o=
n<BR>
&gt;&gt; that.<BR>
&gt;&gt;<BR>
&gt;&gt; Please anyone give suggestion regarding this.<BR>
&gt;<BR>
&gt;<BR>
&gt; I can't really give suggestions on your implementation; there<BR>
&gt; are many implementation level details that impact how you<BR>
&gt; decide to do this.&nbsp; The basic approach would have to involve<BR>
&gt; deferring the decision until later and &quot;back patching&quot; the<B=
R>
&gt; actual use.<BR>
&gt;<BR>
&gt; Gord.<BR>
<BR>
<BR>
<BR>
<BR>
--<BR>
This message has been scanned for viruses and<BR>
dangerous content by MailScanner, and is<BR>
believed to be clean.<BR>
<BR>
<BR>
</FONT>
</P>

</BODY>
<br />--=20
<br />This message has been scanned for viruses and
<br />dangerous content by
<a href=3D"http://www.mailscanner.info/"><b>MailScanner</b></a>, and is
<br />believed to be clean.
</HTML>

------_=_NextPart_001_01C9CC21.01B6F7D1--

--
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 Sun May 3 12:06:47 2009

This archive was generated by hypermail 2.1.8 : Sun May 03 2009 - 12:07:07 PDT