[sv-ec] Resolution of extern methods

Forwarding to the svec.

This thread appears to have come to somewhat of a consensus. I would like the
SVEC to have a chance to start thinking this over, just in case there are
additional corner cases that have been overlooked.


-------- Original Message --------
Subject: Re: Resolution of extern methods
Date: Tue, 24 Oct 2006 13:12:07 -0700
From: Gordon Vreugdenhil <gordonv@model.com>
To: Mark Hartoog <Mark.Hartoog@synopsys.com>
CC: Steven Sharp <sharp@cadence.com>, Francoise Martinolle <fm@cadence.com>, Shalom Bresticker <shalom.bresticker@intel.com>, "Dwivedi, Swapnil" <swapnil_dwivedi@mentor.com>,
Paparao_Kavalipati@mentor.com, Neil.Korpusik@Sun.COM, jonathan.bromley@doulos.com, Greg Jaxon <Greg.Jaxon@synopsys.com>


Mark,

This might not be a bad approach although it would have to
be reconciled with the current LRM requirements that the
declaration form be exactly the same as the extern.

In addition, I don't really want to decouple the defaults
of the extern function from that of the parameterized class
since that would pose redundancy and code re-write issues.
I wouldn't mind adopting a variant of Brad's suggested
"no defaults" approach and say that an extern only defines
the names but that types and defaults come from the class.

So something like:
    function #(type T, parameter P) T[P] C::f(T a);

A slightly weird syntactic form would be:
    C::function T[P] f(T a);

This is similar to Greg's suggestion, just in a different form.

Since the only special cases are "name::function" and "name::task"
this might not be too bad.



I think that what I am hearing as consensus for far is the
following:
   1) C::x  is a reference into a specialization except for (possibly)
      the name of an extern function definition
   2) we need some new syntactic mechanism to describe return
      types of parameterized class methods for parameter dependent types.


If we agree on that, then we have a (simpler) problem of just
agreeing on the syntax.

If we allow the C::function/C::task form, that would actually allow
the current LRM assumptions about "exactly matching form" to be
followed directly.

Gord.


Mark Hartoog wrote:

> I believe in the current LRM the only answer is this is not legal.
> 
> I believe new syntax is needed to support this. 
> 
> As Greg observes C++ syntax is something like
> 
> template<class T> class C {
>     T f(T a);
> };
> 
> template<class T> T C::f(T a) {
> }
> 
> This is treating a function member of a template class as a
> template function. 
> 
> If we had parameterized functions in System Verilog, we could
> treat a function member of a parameterized class as a parameterized
> function.
> 
> function #(type T = bit, int P = 1) T[P] C::f(T a)
>   ....
> endfunction
> 
> This appears to be the most general solution to this problem.
>  
> 
> 
>>-----Original Message-----
>>From: Gordon Vreugdenhil [mailto:gordonv@model.com] 
>>Sent: Tuesday, October 24, 2006 8:30 AM
>>To: Steven Sharp; Francoise Martinolle; Shalom Bresticker; 
>>Mark Hartoog; Gord Vreugdenhil; Dwivedi, Swapnil; 
>>Paparao_Kavalipati@mentor.com; Neil.Korpusik@Sun.COM; 
>>jonathan.bromley@doulos.com; Greg Jaxon
>>Subject: Resolution of extern methods
>>
>>I haven't had any feedback on the following example:
>>
>>   class C #(type T = bit; int P = 1);
>>      extern function T[P] f(T a);
>>   endclass
>>
>>   typedef double T;
>>   localparam P = 2;
>>
>>   function T[P] C::f(T a);
>>      ...
>>   endfunction
>>
>>
>>Since this has a direct bearing on how we might need to 
>>interpret C::T (or similar), I'd like to see if we can figure 
>>out what the answer is on this.
>>
>>Alternatives for the definition of C::f that I see are:
>>   1) not legal
>>   2) legal as is; the context of C::f must reach backwards
>>      to impact the scope for resolving "T" and "P" in the
>>      return type.  This could be quite nasty to implement.
>>   3) must be expressed as:
>>        function C::T[C::P] C::f(T a);
>>      in which case "C::T" in this context must NOT be interpreted
>>      as a specialized type
>>   4) some other ideas?
>>
>>Gord.
>>--
>>--------------------------------------------------------------------
>>Gordon Vreugdenhil                                503-685-0808
>>Model Technology (Mentor Graphics)                gordonv@model.com
>>
> 
> 

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com

-- 
---------------------------------------------------------------------
Neil Korpusik                                     Tel: 408-720-4852
Senior Staff Engineer                             Fax: 408-720-4850
Frontend Technologies - ASICs & Processors (FTAP)
Sun Microsystems
email: neil.korpusik@sun.com
---------------------------------------------------------------------