Re: New draft LRM and progress

John,

I agree, that the changed policy is both the simplest and the cleanest
solution.

  The only "break" in compatibility would be, that sc_signal_resolved is
no longer derived from sc_signal< sc_logic >, since sc_signal< sc_logic,
SC_MANY_WRITERS > is a distinct type.

  But we still have the common signal interfaces and the conversion
operator to sc_logic. So I think it should not do real harm to existing
models.

Same for sc_signal_rv, of course.

Greetings from Oldenburg,
  Philipp

On 24/11/10 10:55, john.aynsley@doulos.com wrote:
> 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.