Re: Named events

All,

I think Bishnupriya's proposal is the cleanest. I do have a few
remarks/questions on that and one extension proposal.

First the remarks/questions:

1) Maybe I misunderstood, but why would sc_core::sc_gen_unique_name()
     have to be called more than once on an sc_object or sc_event?
     The whole purpose of sc_core::sc_gen_unique_name() is to generate
     a unique name in one shot.

     I think it would be sufficient to say that an sc_event's basename is
     generated from calling sc_core::sc_gen_unique_name(seed, true).

2) Why do we need special rules on which characters are/aren't allowed
     in sc_event names? Can't we simply refer to the naming rules for
     sc_objects (given that they share the same namespace)?

3) sc_core::get_top_level_events() and sc_core::sc_find_event() are
     named inconsistently. I think that get_top_level_events() should
     have an sc_ prefix, that is, sc_core::sc_get_top_level_events().

Now the extension proposal:

A) I would like to name explicit kernel events such as
     "const sc_event& sc_signal<bool>::posedge_event()", because of
     user processes that can be sensitive to these events. If we don't
     name these events it becomes very difficult to refer to them e.g.
     when debugging.

B) As far as I can tell, all explicit kernel events are located inside
     primitive channels. In order to be able to distinguish sc_events
     belonging to different primitive channels inside the same module,
     I would like to use the primitive channel's name for the
     hierarchical name (prefix) of an sc_event.

     And maybe we shouldn't stop at primitive channels but allow any
     sc_object (other than module and process) as parent of an sc_event
     to use that sc_object's name to construct the hierarchical name of
     the sc_event.

     This would require something like an additional sc_event c'tor:

         sc_event(const char* name, sc_object* parent);

     This is a simple but less elegant approach. A more elaborate
     solution would keep track of something like the "current sc_object"
     (as we do with module during elaboration and process during
     simulation). I would be happy with the simple approach.

What do you think?

-Martin

On 2010-11-16 22:26, Philipp A. Hartmann wrote:
> All,
>
> I may have another option for naming events, which at least fixes the
> separate, but magically connected namespace issue without sacrificing
> the performance.
>
> Technically, the idea is to add a separate (and optional)
> sc_event_object* member to sc_event, which is derived from sc_object and
> is used for naming events. I'll try to draw a class diagram, hopefully
> it works with all mail clients. Consider the following hierarchy:
>
> sc_object
> ^ +---------------------------+
> | | sc_event |
> | 0..1 +---------------------------+
> sc_event_object ---- | sc_event_object* m_object |
> ^ +---------------------------+
> | ^
> \ ------+----------- /
> |
> sc_named_event (for convenience)
>
> The behaviour would be the following:
>
> sc_event()
> Leaves the allocation of an sc_event_object to the implementation.
> The sc_event_object could stay NULL for dynamic, unnamed events.
>
> sc_event( const char* )
> Creates an sc_event_object with the requested name in the
> regular object hierarchy. No special rules needed.
>
> sc_object* sc_event::get_object() const // return placeholder
> { return m_object; }
>
> const char* sc_event::[base]name() const
> { return m_object ? m_object->[base]name() : NULL ; }
>
> sc_object* sc_event::get_parent_object() const
> { return m_object ? m_object->get_parent_object() : NULL ; }
>
> The sc_event_object class is only a placeholder in the object
> hierarchy, technically implementation defined but with the following
> additional interface:
>
> const char * sc_event_object::kind() const
> { return "sc_event"; }
>
> // return represented event (could also return a reference)
> sc_event * get_event()
> sc_event const * get_event() const
>
> For convenience, an explicit sc_named_event (which always gets an
> automatic name) could also be added:
>
> class sc_named_event
> : public sc_event_object
> , public sc_event
> {
> public:
>
> sc_named_event();
> explicit sc_named_event( const char* name );
> ~sc_named_event();
>
> // disambiguate
> using sc_event_object::basename;
> using sc_event_object::name;
> using sc_event_object::kind;
> using sc_event_object::get_parent_object;
> };
>
> With this proposal, events are optionally part of the regular
> sc_object hierarchy via the placeholder sc_event_object instances.
> Regular traversal and naming expectations hold. Performance should not
> be impaired.
>
> I think, the only drawback would be the deviation in the conversion
> during traversal. Usually, you can query for the kind() of an object
> and do an appropriate dynamic_cast afterwards. With the above proposal,
> you would need to do an get_event() to access the actual event instance:
>
> // somewhere in "top.m"
> sc_event ev1( "my_event" );
> sc_named_event ev2( "my_named_event" );
>
> sc_object* o1 = sc_find_object( "top.sub.my_event" );
> sc_object* o1 = sc_find_object( "top.sub.my_named_event" );
>
> // dynamic cast does not work for plain sc_event, need -> get_event()
> // sc_event * ep1 = dynamic_cast<sc_event*>(o1); // -> NULL
> sc_event * ep1 = dynamic_cast<sc_event_object*>(o1)->get_event();
>
> // for an sc_named_event, usual dynamic_cast would work fine
> sc_event * ep2 = dynamic_cast<sc_event*>(o2);
>
> We could probably add corresponding get_child_events() functions that do
> this filtering, of course. In that case, the sc_event_object could be
> even more restricted to the internal use of the implementation.
>
> Opinions? Could that be a working compromise?
>
> Greetings from Oldenburg,
> Philipp
>
> NB: To avoid bouncing, I've snipped the previous discussion.
>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.