Re: New draft LRM and progress

Philipp,

I think the current solution - having class sc_signal_resolved: public
sc_signal<..., SC_MANY_WRITERS> - is the simplest. Does it have any bad
consequences re. type incompatibility or partial template specialization?

John A

From:
"Philipp A. Hartmann" <philipp.hartmann@offis.de>
To:
Alan Fitch <alan.fitch@doulos.com>
Cc:
john.aynsley@doulos.com, systemc-p1666-technical@eda.org
Date:
23/11/2010 19:10
Subject:
Re: New draft LRM and progress

Alan,

comments on some of your comments below.

On 23/11/10 17:47, Alan Fitch wrote:

> 6.5.2
> Does sc_unnamed need adding to the list of namespaces at the beginning
> of the standard? Should (or could) sc_unnamed be nested in sc_core?

Personally, I would prefer to have it outside of sc_core to avoid the
extra typing. But I guess, in that case it needs to be added to the
list at the beginning.

> 6.6.4
> p66
>
> In the description of void swap(sc_process_handle &) it says that either
> handle may be invalid. If *both* were invalid, would it still be true
> that H1<H2 would swap to H2 < H1 ? Or is it just invisible since H1 < H2
> and H2 < H1 would both return false anyway?

Yes, the ordering needs to be swapped as well, even for invalid handles.
Note, that invalid handles not necessarily return false for both H1<H2
and H2<H1, depending on potentially still associated process objects.

> Also later on (6.6.6) it says that a call to the process control member
> functions on an invalid handle shall generate a warning - should that
> also happen on a call to swap()?

I think, no. Swap should similar to copying or assignment in that
regard. These operations are all supposed to work for all possible
handle values.

> 7.13
> I don't think Philipp mentioned this in his review - sc_signal_resolved,
> does that need an implementation of get_writer_policy?
>
> Similarly for sc_signal_rv 7.17.2

Since these two functions support many writers, calling
get_writer_policy should return SC_MANY_WRITERS.

  I just saw, that the current wording changes the base class to
sc_signal< sc_logic/lv<W>, SC_MANY_WRITERS >, the correct values is
returned from the base class implementation.

  I'm not sure, if we should stick with the inconsistency to inherit
from sc_signal< sc_logic/lv > as before -- thus inheriting SC_ONE_WRITER
-- and add explicit new implementations for get_writer_policy returning
SC_MANY_WRITERS. Opinions?

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 · http://offis.de/en/
Phone/Fax: +49-441-9722-420/282 · PGP: 0x9161A5C0 · Skype: phi.har
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.