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