[sv-ec] RE: Matching defaults

I'm still not happy with prototype vs definition defaults:

just consider this example:

module top;
     class C;

         extern task t(input int x = 1);
         endclass

     	   task C::t(input int x = 2);
          $display(x);
     	   endtask

     C c;
     initial begin
         c.t();
     end
endmodule

what will be the output here ? and why ?

whatever was selected by compiler - the code is just confusing ...

what is the point to have a second (not chosen) value in a code ?
is there any possbility (another call ?, another place ?) when the second
one will be selected in compilation ?

mayby the default specification for a given argument shall be allowed in
prototype *or* in definition, but *not* in both at once ?

Mirek

-----Original Message-----
From: Rich, Dave [mailto:Dave_Rich@mentor.com] 
Sent: 18 lipca 2008 17:16
To: Mirek Forczek; Bresticker, Shalom; Surya Pratik Saha;
sv-ec@server.eda.org
Subject: Matching defaults

(I've changed the subject line and removed sv-bc from the discussion)

There are a few key differences with the functionality of default arguments
between C++ and SV. 

Because SV has argument referencing by name, not just by position, SV
argument names much match, so defaults can be placed on any argument, not
just the trailing one as in C++. 

C++ allows you to specify defaults in the prototype, and add more
defaults in the actual definition, but not override an existing default.

C++ requires constant default values, while SV allows non-constant
expressions. With non-constant expressions came the desire to override the
default expressions.

When you have call to a virtual method in SV, the compiler needs to know
exactly which arguments are required by name and which ones are optional,
not just the total number of arguments. This is why presence of a default is
required to match for a virtual method in a subclass, while an override of
the default is not required to match to allow an override.

For extern (out-of-class-body) declarations, I've seen code written for at
least 3 different implementations. Default allowed in: prototype only,
definition only, and required in both. The latter being what's currently
required by the LRM.

Dave




> -----Original Message-----
> From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org]
On
> Behalf Of Mirek Forczek
> Sent: Friday, July 18, 2008 2:53 AM
> To: 'Bresticker, Shalom'; 'Surya Pratik Saha'; sv-ec@server.eda.org;
sv-
> bc@server.eda.org
> Subject: [sv-bc] RE: [sv-ec] Wrong SV code in VMM
> 
> Hi,
> 
> ad 2)
> 
> Please note that in C++ in example having the default in both places
is
> considered as an error.
> 
> And such resolution is reasonable somehow: once you allow the default
to
> be
> specified in two places, there is a risk that one othe placed will be 
> updated later and the other not, which will lead to hard-tracking 
> bugs.
> 
> Regards,
> Mirek
> 
> -----Original Message-----
> From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org]
On
> Behalf Of Bresticker, Shalom
> Sent: 18 lipca 2008 11:41
> To: Surya Pratik Saha; sv-ec@server.eda.org; sv-bc@server.eda.org
> Subject: RE: [sv-ec] Wrong SV code in VMM
> 
> Hi,
> 
> You're correct, there is no SV 1800-2008 LRM.
> 
> 1. You're correct, `" is only defined in macro text. In fact, this is
one
> of
> the gotchas appearing in the SV Gotchas paper I will be presenting at 
> Boston SNUG in September.
> 
> 2. In Draft 6, 8.23 says,
> 
> "The out-of-block method declaration shall match the prototype
declaration
> exactly; the only syntactical difference is that the method name is 
> preceded by the class name and the class scope resolution operator 
> ::."
> 
> That seems to require that the default appear in both places.
> 
> Regards,
> Shalom
> 
> > -----Original Message-----
> > From: owner-sv-ec@server.eda.org
> > [mailto:owner-sv-ec@server.eda.org] On Behalf Of Surya Pratik Saha
> > Sent: Friday, July 18, 2008 12:19 PM
> > To: sv-ec@server.eda.org; sv-bc@server.eda.org
> > Subject: [sv-ec] Wrong SV code in VMM
> >
> > Hi,
> > I am not sure whether this is the appropriate body to discuss about 
> > this matter, but since it is related to SV, so I am sending the
mail.
> > If it is not appropriate, please ignore this.
> >
> > I have downloaded the freely available VMM release (version 1.0.1), 
> > where it is mentioned it is compatible with SV 1800-2008. But I
don't
> > think there is any SV 1800-2008 LRM.
> > Or do I miss any?
> >
> > Moreover, I have seen following problems in that VMM.
> > 1) A special syntax used with `".
> > Consider the e.g:
> > `define VMM_CHANNEL xxx
> > module top;
> >     initial begin
> >         $display("VMM_CHANNEL %s", `"`VMM_CHANNEL`");
> >     end
> > endmodule
> >
> > Here `" is used in normal position. But as per SV 1800-2005 LRM, `"
> > can only be used in macro text. Is it changed later?
> >
> > 2) Function declaration having default argument, though body does
not
> > have.
> > Consider the e.g.:
> > module top;
> >     class C;
> >         extern function int f(input x, input y = 1);
> >         endclass
> >     function int C::f(input x, input y);
> >         f = x;
> >     endfunction
> >     int x;
> >     C c;
> >     initial begin
> >         x = c.f(1);
> >     end
> > endmodule
> >
> > Where for 'y', the function declaration is having default argument 
> > value, whereas the body does not have. I am not sure whether LRM 
> > supports that or not.
> >
> > --
> > Regards
> > Surya
> ---------------------------------------------------------------------
> 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, and is believed to be clean.
> 
> 
> 
> --
> 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.