Re: Summary of minor issues

All,

A week's vacation, a volcano eruption, a couple of industry events, and
suddenly a week becomes a month. Anyway, now I'm back.

I will execute the changes described below. Personally, I have some
reservations about the proposed change to the definition of sc_mutex and
sc_semaphore (i.e. derive from sc_object instead of sc_prim_channel)
because, strictly speaking, this change is not backward-compatible with
1666-2005. However, we can still change our minds before going to ballot.

John A

From:
john.aynsley@doulos.com
To:
systemc-p1666-technical@eda.org
Date:
09/04/2010 13:37
Subject:
Re: Summary of minor issues
Sent by:
owner-systemc-p1666-technical@eda.org

Last chance for people to comment before I execute this set of changes....

Thanks,

John A

From:
john.aynsley@doulos.com
To:
systemc-p1666-technical@eda.org
Date:
31/03/2010 12:20
Subject:
Summary of minor issues
Sent by:
owner-systemc-p1666-technical@eda.org

I summarise below the conclusions we have reached so far on a number of
minor issues. Please respond if you do not agree or wish comment further;
otherwise I will go ahead and implement these changes in the LRM.

Note: whether or not you respond on the reflector at this point, you will
still have chance to review the draft LRM and provide feedback well before
we go to ballot.

* 4.5.2 It is unclear whether or not sc_set_stop_mode() is meant to be
called during simulation. The LRM says nothing. The OSCI implementation
reports a warning if it is called during simulation. Should we rule that
it is an error to call sc_set_stop_mode() during simulation, or should it
be allowed and supported?

TENTATIVE CONCLUSION: Make it an error to call sc_set_stop_mode() during
simulation, which presumably means after start_of_simulation() ???

* 5.2.9 The LRM does not make it clear whether or not a trailing
semicolon is required or permitted after the invocation of macros
SC_METHOD, SC_THREAD, SC_HAS_PROCESS etc, although a trailing semicolon is
shown in every example.

CONCLUSION: Make the semicolon mandatory.

* 5.5.7 It is not crystal clear whether the following is legal:

sc_process_handle h1, h2;
SC_FORK
 h1 = sc_spawn(...),
 h2 = sc_spawn(...)
SC_JOIN

CONCLUSION: Make this legal.

* 6.27 and 6.29 The classes sc_mutex and sc_semaphor are derived from
sc_prim_channel, implying that they cannot be instantiated during
simulation. This is an unnecessary restriction which prevents the dynamic
creation of mutexes and semaphores for use in synchronizing dynamic
processes.

TENTATIVE CONCLUSION: Change the LRM to make these classes derived from
sc_object, instead of sc_prim_channel. (This introduces a minor backward
incompatibility - in the unlikely event of someone having derived from one
of these classes and used request_update/update.)

* Jerome's enhancement request for a process id to allow processes to be
catalogued

CONCLUSION: Add two new methods sc_process_handle::operator< and
sc_process_handle::swap with semantics as discussed.

Thanks,

John A

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