Re: sc_event_and/or_list

Ok, I had a misconception in my last mail. Actually, dynamic
sensitivity does not change the event lists (in terms of represented
events) in the current OSCI implementation. This removes my main
concern mentioned in the last mail. Sorry for that.

So the current situation is as follows:

 - changing wait()/next_trigger() to take "const sc_event_*_list &"
   works fine (only some additional 'const' qualifiers required,
   no additional 'mutable' or 'const_cast').
   -> would enable temporary sc_event_*_lists as parameters

 - For efficiency reasons, the operators &,| for building
   event lists could keep their mutating behaviour.

 - Wrt to the public interface of sc_event_*_list objects, I have
   no strong opinion. Except that obvious things like begin(), end(),
   size(), swap() should probably be part of it. :-)

John, if you're interested in my experimental code, please let me know.

Thanks,
  Philipp

On 28/09/10 22:18, Philipp A. Hartmann wrote:
> 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.