Hello Jerome, all,
thanks for your feedback. Some comments below.
On 10/03/10 16:22, Jerome CORNET wrote:
> On 3/9/2010 9:42 PM, Philipp A. Hartmann wrote:
>> Looking forward to any comments, opinions, and criticism ... ;-)
>>
> we have read your proposition and are very favorable to it.
[snip description of some benefits and additional use case example]
> I would also add that this proposal would also enhance introspection in
> SystemC, as this would allow CAD tools to identify groups of ports and
> also provide added value in this area.
The current proposal is tries to not mess with the SystemC hierarchy
directly. If you have a vector of two elements with name "vec" in the
module "top", you would currently get the following child objects:
top.vec // vector itself
top.vec_0 // first element
top.vec_1 // second element
The reason for this has been
- 5.15.1: Only module objects and process objects can have children.
- Try not to break existing hierarchy traversal code, that relies on
the first bullet.
So as it stands currently, it may be difficult to directly identify
the objects belonging to a particular vector, especially combined with
delayed initialisation (see also standardised container comment, below).
> Some comments now:
>
> - It would be beneficial for the class sc_port_vector to also provides
> bind() and operator() methods that would call bind()/operator() on each
> element of the vector. This would eliminate the need for possible
> buggy for loops once and for all.
Yes, I agree that this is very useful. Attached is our current
implementation of the sc_port_vector class, which provides several
bind() functions (and corresponding operator()). This enables bindings
of (sub-)vectors, whenever elements in the two vectors are binding
compatible (e.g. vector of ports to vector of channels).
> - It would indeed be desirable to support derived types, including in
> the sc_port_vector. One could then use this container to also support
> TLM-2.0 sockets.
Indeed. Polymorphic types are meant to be supported already, in case
you have a Creator function (object), that creates and returns derived
types. This may need some clarification in the wording for the
standard, though.
> A proposal: why not standardizing a common container for TLM-2.0
> sockets? (this would be a variant of sc_port_vector/sc_vector
> + instantiation functor, as sockets are basically inheriting from
> sc_port or sc_export).
Given that TLM is to be added to IEEE 1666, I think this might be a
useful enhancement. For sc_export itself, a specialisation would then
be needed as well, especially regarding the binding support.
> - A minor remark: check the const and references things. For instance
> sc_vector::init should take a const size_type as parameter (even if
> the semantics is pass-by-value this helps the compiler),
Sure, why not.
> and the Creator functor should be passed at least by reference (if not
> by const reference) to sc_vector::init<Creator>.
For the Creator functor, I tried to follow the approach of the C++
standard library (and Boost, etc) in such cases. The main reason for
this is flexible support for function objects (apart from plain function
pointers).
- If you pass the functor by (non-const) reference, temporary objects
can not be passed as argument (e.g. the ones return by (sc_)bind).
- If you pass it by const-reference, the operator() of the functor
has to be const as well.
But since these are constructor calls that are only allowed during
elaboration, it should not be a performance issue anyhow.
> - Another question that we are asking ourselves: should the container
> actually used really be implementation-dependent?
> Why not standardizing on STL's std::vector, whose implementation is
> already left to optimizations?
When I first implemented this, it has been more or less an
"elaboration-only" variant of a container like Boost's ptr_vector and
has not been restricted to objects derived from sc_object.
Since the module/port/channel/... use cases are by far the most
frequent ones in SystemC, and those _are_ derived from sc_object, we
could of course standardise the internal container to
std::vector< sc_object* > and add a function
std::vector< sc_object* > const & get_elements() const
to improve the introspection possibilities.
If we decide to put the elements as child objects of the vector itself
(see above), it may even be a consequence of the then required
implementation of get_child_objects() in the sc_vector class.
Greetings from Oldenburg,
Philipp
-- Philipp A. Hartmann Hardware/Software Design Methodology Group OFFIS 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.
This archive was generated by hypermail 2.1.8 : Wed Mar 10 2010 - 09:10:11 PST