Re: Virtual bind operators

Sorry, there's a '&' missing in my example:

  sc_port< sc_signal_in_if<int>, 0 > in_multi;
  sc_in<int> in_single;

  // is the following allowed?
  static_cast< sc_port_b< sc_signal_in_if<int> > & > // ref!
     ( in_single ).bind( in_multi );

P.

On 20/10/10 11:07, Philipp A. Hartmann wrote:
> John,
>
> Im fine with the restricted interface for sc_in<T>::bind(). Do we need
> to detect explicit calls to the inherited versions?
>
> sc_port< sc_signal_in_if<int>, 0 > in_multi;
> sc_in<int> in_single;
>
> // is the following allowed?
> static_cast< sc_port_b< sc_signal_in_if<int> > >
> ( in_single ).bind( in_multi );
>
> Wrt to your second point, I'm not sure, if I understand you correctly.
> I still think that the different bind() functions in sc_in<> should be
> virtual (and be required to call the method of the base class). This is
> more related to user-defined classes derived from sc_in, than actually
> using sc_in<> via a base-class pointer.
>
> Thanks,
> Philipp
>
> On 19/10/10 10:27, john.aynsley@doulos.com wrote:
>> Philipp, Jerome, All,
>>
>> Regarding the signature void bind ( sc_port<sc_signal_in_if<T>, 1>& );
>> note that this is explicitly restricted to binding to a port with N = 1,
>> because those are the semantics required for this port specialization
>> (signal ports cannot be multiports). I think we should keep this
>> restriction, i.e. not change the signature.
>>
>> My original point was that, unlike every other operator()/bind pair, the
>> operator()/bind methods of sc_in<> , sc_in<bool> , and sc_in<sc_logic> are
>> explicitly required by the LRM to call the bind method of the base class.
>> I would agree that it would be more consistent to change the LRM to
>> mandate that sc_in<T>::operator() shall call this->bind, and that bind be
>> virtual. However, sc_in<T>::bind(...) cannot get called through a base
>> class ptr because there is no method with that signature in class
>> sc_port_b. That's fine with me.
>>
>> John A
>>
>>
>>
>>
>> From:
>> "Philipp A. Hartmann" <philipp.hartmann@offis.de>
>> To:
>> john.aynsley@doulos.com
>> Cc:
>> Jerome CORNET <jerome.cornet@st.com>, "systemc-p1666-technical@eda.org"
>> <systemc-p1666-technical@eda.org>
>> Date:
>> 18/10/2010 16:54
>> Subject:
>> Re: Virtual bind operators
>>
>>
>>
>> John,
>>
>> currently, sc_in<T> has three pairs of bind()/operator()
>>
>> The first two are inherited from sc_port_b< sc_signal_in_if<T> >:
>>
>> void bind ( const sc_signal_in_if<T>& );
>> void operator() ( const sc_signal_in_if<T>& );
>>
>> void bind ( sc_port<sc_signal_in_if<T>, 1>& );
>> void operator() ( sc_port<sc_signal_in_if<T>, 1>& );
>>
>> We could even consider to stop mentioning them explicitly and replace
>> them with:
>>
>> using sc_port< sc_signal_in_if<T>, 1 >::bind;
>> using sc_port< sc_signal_in_if<T>, 1 >::operator();
>>
>> But there's an additional pair to support binding to inout ports as
>> well, which is why we need the repetition or the using declaration:
>>
>> void bind ( sc_port<sc_signal_inout_if<T>, 1>& );
>> void operator() ( sc_port<sc_signal_inout_if<T>, 1>& );
>>
>> So this should probably be changed to
>>
>> virtual void bind( sc_port_b< sc_signal_inout_if<T> > & );
>> void operator()( sc_port_b< sc_signal_inout_if<T> > & );
>>
>> Similar for the specialisations for bool and sc_logic.
>> I have not checked this, though.
>>
>> Thanks,
>> Philipp
>>
>> On 18/10/10 17:38, john.aynsley@doulos.com wrote:
>>> Philipp, All,
>>>
>>> I agree with having "virtual bind" for sc_port_b, sc_export,
>>> tlm_analysis_port, tlm_base_initiator/target_socket, and
>>> multi_passthrough_initiator/target_socket
>>>
>>> I am not sure about sc_in<> etc, because as things stand bind() and
>>> operator() are each explicitly obliged to call sc_port_b::bind(). What
>> do
>>> you think?
>>>
>>> Thanks,
>>>
>>> John A
>>>
>>>
>>>
>>>
>>> From:
>>> "Philipp A. Hartmann" <philipp.hartmann@offis.de>
>>> To:
>>> Jerome CORNET <jerome.cornet@st.com>
>>> Cc:
>>> "systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org>,
>> John
>>> Aynsley <john.aynsley@doulos.com>
>>> Date:
>>> 14/10/2010 09:17
>>> Subject:
>>> 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.