Re: sc_vector proposal

Philipp,

I am fine with a verbose name in this case, because it is doing something
non-obvious so we would want it to stand out.

I agree with sc_vector_assembly<T,MT>. Does this need to be in the LRM?
Which bits of it are visible in application code? Can you give some
examples?

John A

From:
"Philipp A. Hartmann" <philipp.hartmann@offis.de>
To:
john.aynsley@doulos.com
Cc:
systemc-p1666-technical@eda.org
Date:
10/11/2010 11:35
Subject:
Re: sc_vector proposal

John,

I'm fine with sc_assemble_vector, although it's quite verbose. But I
see your point in having a name related to sc_vector.

  Shall we change the name of the implementation-defined helper class
sc_vector_view<T,MT> as well? sc_vector_assembly<T,MT> perhaps?

Thanks,
Philipp

On 10/11/10 12:28, john.aynsley@doulos.com wrote:
> Philipp, All,
>
> Regarding the binding iterators: Having vector binding capability is
> really cool, and you do indeed want a way to bind part-vectors. Given
that
> there is some precedent in STL, the approach you have chosen is fine,
i.e.
> returning the position of the next unbound element.
>
> Regarding the name sc_view: It is just a name, but I think we could do
> better. I got the database reference, but I want a name that tells me
that
> I'm doing something related to vectors. I propose
>
> sc_assemble_vector(initiator_vec, &Initiator1::port).bind(
> sc_assemble_vector(target_vec, &Target::xp) );
>
> What do people think?
>
>
> Regarding the creator: Okay, I buy that, unless anyone else has any
smart
> ideas?
>
> John A
>
>
>
>
> From:
> "Philipp A. Hartmann" <philipp.hartmann@offis.de>
> To:
> john.aynsley@doulos.com
> Cc:
> systemc-p1666-technical@eda.org
> Date:
> 09/11/2010 18:36
> Subject:
> Re: sc_vector proposal
>
>
>
> John,
>
> thanks for your comments and your nice review of the proposal.
> Please find my answers to your questions embedded below.
>
> On 09/11/10 14:06, john.aynsley@doulos.com wrote:
>
> [snip basic feature description]
>
>> Then we add a few wrinkles. It is possible to bind a vector-of-ports to

> a
>> vector-of-channels directly, with no explicit loop, e.g.
>>
>> module_inst->ports.bind( sigs ); // ports is a vector-of-ports

>> and sigs is a vector-of-sigs
>>
>> Very nice. It is also possible to bind just a subset of the
>> vector-of-ports, then come back for another pass later:
>>
>> typedef sc_vector<sc_inout<int> > port_type;
>> port_type::iterator it;
>>
>> // Bind upper half of ports vector to hi_sigs
>> it = module_inst->ports.bind( hi_sigs.begin(), hi_sigs.end() );

> //
>> hi_sigs.size() < ports.size()
>>
>> // Bind lower half of ports vector to lo_sigs
>> it = module_inst->ports.bind( lo_sigs.begin(), lo_sigs.end(),
> it);
>> // Notice binding starts from position 'it' within ports vector
>>
>> The above syntax - having bind return the position of the 1st unbound
>> element - seems a little arcane to me. Are we all okay with it?
>
> Returning the "last" iterator follows the approach known from some of
> the iterator-based STL algorithms, like std::copy or std::transform.
> To me, this is the simplest way to define the interface. But I'm free
> to any suggestions in that area.
>
> Note, that the user can of course ignore the return value of the bind
> function and use an explicit iterator for the second bind offset:
>
> module_inst->ports.bind( lo_sigs.begin(), lo_sigs.end()
> , module_inst.begin() + hi_sigs.size() );
>
> If we feel, that this iterator-based interface is too complex to
> understand or describe, we can also drop it from the standard. Manually
> looping over parts of the vectors is still possible and maybe easier to
> explain:
>
> port_type it = module_inst.ports.begin();
>
> for( int i=0; i<hi_sigs.size(); ++i, ++it );
> it->bind( hi_sigs[i] );
>
> for( int i=0; i<lo_sigs.size(); ++i, ++it );
> it->bind( lo_sigs[i] );
>
> The returned iterator from the bind() calls can also be used to check,
> if all elements have been bound:
>
> sc_assert( it == module_inst->ports.end() ); // all bound
>
>> But sometimes, rather than having a vector-of-ports, you might have a
>> vector-of-modules each containing a single port. In this case it is
>> possible to treat these ports distributed across multiple modules as
one
>
>> vector, using sc_view. For example:
>>
>> struct Initiator1: sc_module
>> {
>> sc_port<i_f> port;
>> ...
>> struct Target: public sc_module, private i_f
>> {
>> sc_export<i_f> xp;
>> ...
>>
>> sc_vector<Initiator1> initiator_vec;
>> sc_vector<Target> target_vec;
>>
>> sc_view(initiator_vec, &Initiator1::port).bind( sc_view
>> (target_vec, &Target::xp) );
>>
>> In the above
>> sc_view(initiator_vec, &Initiator1::port) creates a
>> vector-of-ports
>> sc_view(target_vec, &Target::xp) creates a vector-of-exports
>> .bind() does a vector-to-vector bind
>>
>> The semantics are very nice, but I am not particularly happy with the
> name
>> sc_view, because this is not suggestive of what is actually happening,
>> that is, gathering together a vector from a set of elements distributed

>> across another vector. Is there a precedent for the name sc_view,
> Phillip?
>> How about something like sc_gather or sc_make_vector or sc_vectorize
>> instead?
>
> I don't have a strong feeling about the name sc_view. Especially, since
> I'm not particularly talented in given well-descriptive names.
>
> The chosen name sc_view originates from the database world, where a
> view is some kind of a "stored query", which can then be manipulated
> more easily. See e.g. http://en.wikipedia.org/wiki/Database_view
>
> The cause is more or less the same here: With sc_view, you pre-select
> a given member of the vector, without actually creating a "real"
> sc_vector object. Only accesses via this "view" are forwarded to the
> _member object_ of the underlying vector element, instead of the element
> itself.
>
> I could think of other names like
> sc_member[_view]()
> sc_children()
> sc_select[ion]()
>
> But as I said, I'm not really good at this. ;-)
>
> [snip get_elements]
>
>> Finally, in the special case of a vector-of-modules, it is possible to
>> pass extra arguments to the module constructor, e.g.
>>
>> struct my_module: sc_module
>> {
>> my_module(sc_module_name n, string weird_arg ) {...}
>> ...
>> ...
>> sc_vector<my_module> my_vec;
>>
>> struct my_module_creator
>> {
>> my_module_creator( string arg ) : weird_arg(arg) {}
>>
>> my_module* operator() (const char* name, size_t)
>> {
>> return new my_module(name, weird_arg );
>> }
>> string weird_arg;
>> };
>> ...
>> my_vec.init(N, my_module_creator("The Creator"));
>>
>> This works, but creating the function object feels like having to jump
>> through hoops. I think regular users are going to find it confusing.
Can
>
>> we do any clever tricks to make it easier to use?
>
> The reason for the complexity is two-fold:
>
> - The Creator needs to receive the designated name for the element
> (and, for convenience, the current index)
> - The Creator may need to have a local state e.g. to store
> or generate additional arguments.
>
> To use a custom Creator, the easiest/best solution depends on the
> current situation. If you have some globally accessible way to chose
> your additional arguments, you may get away with a plain function:
>
> my_module* my_module_creator_func( const char* name, size_t i )
> {
> return new my_module( name, WEIRD_ARG );
> }
> my_vec.init(N, my_module_creator_func );
>
> Another quite simple way is to define a local member function in the
> surrounding module and use sc_bind for the creator. This way, you can
> access the whole state of the owning module during creation and do all
> kinds of nice stuff, like binding transport functions etc:
>
> SC_MODULE(parent)
> {
> sc_vector< my_module > my_vec;
> std::string weird_arg;
>
> // member function as creator to use with sc_bind()
> my_module* init_element( const char* n, unsigned i )
> {
> my_module * mod = new my_module( n, weird_arg );
> mod->register_invalidate_direct_mem_ptr( this,
> &parent::invalidate_direct_mem_ptr, i );
> return mod;
> }
>
> SC_CTOR(parent)
> {
> // use sc_bind, "this" + placeholders as creator
> // note: you may need to use sc_unamed::_1 in SystemC 2.3
>
> my_vec.init( N, sc_bind( &parent::init_element, this, _1, _2 ) );
> }
> };
>
> To me, the above is as easy as it can get in current C++.
> Of course, C++0x lambdas will rock here in the future:
>
> std::string weird_arg;
> my_vec.init( N,
> [&]( const char*, size_t i)
> { return new my_module( n, weird_arg ); }
> );
>
> I'm of course interested in any simpler approach to custom element
> creation. But I've spent some time on this issue and could not come up
> with any easier solution for supporting arbitrary constructor
signatures.
>
> I can see that this is not really part of C++/SystemC 101, but at
> least it's consistent with other functor APIs in C++, like Compare (in
> std::map and std::sort) or Function in std::for_each.
>
> Greetings from Oldenburg,
> Philipp
>

-- 
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.