Re: sc_event_and/or_list

John, Tor, All,

from my POV, the most important issue in this regard is the definition
of value/ownership semantics of such lists in their interaction with the
simulation kernel.

  As of know, the implementation is completely free to modify the passed
event lists (as the interface suggests). Having these lists as proper
objects (e.g. module members) would imply, that the kernel should NOT
modify the passed objects, right?

  Changing the signatures of wait() and next_trigger to take event lists
as const references would be possible and even backwards-compatible (and
would solve the return-by-value issue, John mentioned).

Example:

  sc_event_and_list el1 = e1 & e2 & e3;
  sc_assert( el1.size() == 3 ); // 3 events in list

  // should el1 be unchanged ? (IMHO, yes)
  sc_event_and_list el2 = el1 & e4;
  sc_assert( el1.size() == 3 && el2.size() == 4 ); // (1)

  // should el1 be unchanged after wait? (IMHO, yes)
  wait( el1 );
  sc_assert( el1.size() == 3 ); // (2)

With the current OSCI PoC simulator, the assertions (1) and (2) would
NOT hold.

  On the other hand, changing operators &,| and the
wait()/next_trigger() functions to make an explicit copy internally
comes with quite some runtime overhead: In a quick and dirty test I've
measured up to +30% for naïve enforcing (1)+(2) and +7% for enforcing
(2) only.

Opinions?

Greetings from Oldenburg,
  Philipp

On 28/09/10 13:41, john.aynsley@doulos.com wrote:
> Tor, All,
>
> I think we have a consensus that we want to make the change such that
> sc_event_and/or_list can be instantiated as proper objects and act as
> containers for events that can be passed to wait() and next_trigger() (at
> least).
>
> Would you (or someone else) please make a specific proposal for classes
> sc_event_and_list and sc_event_or_list to go into the LRM. I started
> prototyping this months back and ran into some C++ issues. As I recall
> from my experiments, the prototype wait(sc_core::sc_event_or_list&)
> currently precludes having something like wait(all_events()); where
> all_events() returns an event list by value. So we need a set of
> signatures for the constructor(s)/operators of the event list classes that
> work with the current signatures of wait/next_trigger.
>
> John A

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