Re: Virtual bind operators

Jerome,

On 14/10/10 09:54, Jerome CORNET wrote:

[snip]

> If I understand well, with what you propose below, we would avoid
> to write the using clause for the operator() and could focus on overloading
> the bind() methods only?

Exactly. If we require, that the operator() implementations call the
corresponding virtual bind functions, you would only need to implement
those.

If we adopt this change, we should look at the other operator()/bind()
pairs in

 - sc_export (5.12)
 - sc_in<> (6.8, 6.9, 6.10)
 - tlm_analysis_port (18.4.1) (not sure here)
 - tlm_base_initiator/target_socket (14.2.2)

to make this consistent.

Note, in 5.11.7 (sc_port::bind), there's a typo: "sc_export<T>::operator
&" is missing the 'IF'

Greetings from Oldenburg,
  Philipp

>
> -----Original Message-----
> From: Philipp A. Hartmann [mailto:philipp.hartmann@offis.de]
> Sent: Wednesday, October 13, 2010 10:04 PM
> To: Jerome CORNET
> Cc: systemc-p1666-technical@eda.org; John Aynsley
> Subject: Re: Virtual bind operators
>
> Jerome, All,
>
> I'm not sure, if I understand the use-case correctly.
> Consider the following example:
>
> template<typename IF>
> struct my_port : sc_core::sc_port<IF>
> {
> typedef sc_core::sc_port<IF> base_port;
>
> // override port-interface binding
> virtual void bind( IF& iface )
> {
> // do something special
> // call base function
> base_port::bind( iface );
> }
>
> // still needed for port-port binding due to name-hiding
> using base_port::bind;
>
> // inherit operator()
> };
>
> Is this the use-case you had in mind?
>
> In that case, I would propose to make only bind() virtual and require
> the operators to call exactly this virtual bind function (which is not
> required as of now):
>
> template< typename IF >
> struct sc_port_b
> {
> void operator()( IF& iface); // Effect: this->bind(iface)
> void operator()(sc_port_b<IF> & port); // Effect: this->bind(port)
>
> virtual void bind(IF &);
> virtual void bind(sc_port_b<IF> &);
> };
>
> This would make the above example work, if the operator() functions are
> required to call the virtual bind() function. Do I miss something? Is
> there a reason, to make the operators virtual as well? We would still
> want them to call their virtual bind() siblings, right?
>
> Thanks,
> Philipp
>
> On 13/10/10 16:14, john.aynsley@doulos.com wrote:
>> Jerome, All,
>>
>> The next item on the list is virtual bind operators. I include the text
>> from Jerome's original proposal below.
>>
>> Thoughts?
>>
>> John A
>>
>>
>> Another area that can be improved with only minor changes is the
>> sc_port/sc_export classes:
>>
>> * The various bind() and operator() methods are not declared virtual. This
>> means that when someone wants to overload these methods in a user class
>> derived from sc_port or sc_export, he has to declare and provide
>> implementation for all the variants. For instance the user could want to
>> overload the sc_port binding to an interface, and he has to also declare
>> and implement all the other bindings. This is a real pain when
>> implementing user protocol classes derived from sc_port or sc_export.
>>
>> * Similarly, I would propose to declare virtual the various bind() and
>> operator() methods in the TLM 2.0 sockets classes
>> (tlm_base_initiator_socket and tlm_base_target_socket).
>>
>> * The class sc_port is template on IF (interface), N (max number of
>> connections) and POL (policy), and derives from the sc_port_base class.
>>
>> * The declaration of sc_port binding on another sc_port does not seems
>> consistent:
>> void bind(sc_port<IF, N> &);
>>
>> This means that a sc_port "templatized" with N=2 can only connect to
>> another port that is "templatized" with the very same N whereas you can
>> logically connect a sc_port with N=2 to 2 sc_port that would have N=1 (for
>> instance). In this area, I have seen many implementations (including the
>> reference OSCI implementation) that just don't comply with the norm in
>> order to allow these logical connections.
>>
>> So, what is needed is something like this:
>> virtual void bind("any_port" &);
>> sc_port_base could be a candidate for "any_port" but it is not template on
>> IF. Actually, if we look at some implementations, we see that they do use
>> an intermediate class called sc_port_b, that is template on IF.
>>
>> So the proposal is:
>>
>> - Standardize the class sc_port_b<IF>, that inherits from sc_port_base and
>> that contains the following bind/operator functions:
>>
>> virtual void operator() (IF &);
>> virtual void operator() (sc_port_b<IF> &);
>>
>> virtual void bind(IF &);
>> virtual void bind(sc_port_b<IF> &);
>>
>> The class sc_port would then inherit from sc_port_b. This is just a
>> standardization (+ virtual keyword) of what is already implemented in many
>> simulators, including the OSCI reference one. Any user that implements
>> class derived from sc_port will need that sc_port_b class for the same
>> reason. A perfect example of that are the OSCI TLM 2.0 sockets, that
>> explictly make use of sc_port_b (see tlm_base_initiator_socket_b and
>> tlm_base_target_socket_b) to allow binding of sockets with different N and
>> POL parameters, but with matching BUSWIDTH, FW_IF and BW_IF.
>>
>>
>
>

-- 
Philipp A. Hartmann
Hardware/Software Design Methodology Group
OFFIS Institute for Information Technology
R&D Division Transportation · FuE-Bereich Verkehr
Escherweg 2 · 26121 Oldenburg · Germany
Phone/Fax: +49-441-9722-420/282 · PGP: 0x9161A5C0 · http://www.offis.de/
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.