Review: New draft LRM and progress

John, all,

we did some quick internal review of the current draft.
The following comments popped up during this.

4.3.4 Namespaces and internal naming

  The clarification adds 'and definition' to the required namespace
  location of added names. Since every (regular) definition is a
  declaration as well, this seems redundant.

  Moreover, a preprocessor macro _definition_ (#define) may suddenly
  be covered by this as well, which can not be placed in any namespace.
  Should there be a note about this?

  Note: Alan already mentioned the probably missing 'sc_unnamed'
  namespace. sc_unnamed::_X should not be imported to the global
  namespace by "systemc.h".

6.1.1 #include "systemc"

  "The header file named systemc shall add the names sc_core and sc_dt
   to the declarative region in which it is included, _and_these_two_
   _names_only_."

   -> sc_unnamed, sc_main declaration (optional) missing

  "... shall not introduce ... any other names from this standard or
   any names from the standard C or C++ libraries"

  Obviously, this can't be fulfilled by any implementation, if
  'systemc' is the only included file. At least for e.g. 'sc_bind',
  get_child_objects(), or 'sc_exception', other names are definitely
  required (at least 'boost' and 'std').

  I also don't know how to handle macros here.
  They are a different kind of 'names', right?

6.6.5 sc_process_handle::get_parent_object
6.16.7 sc_object::get_parent_object

  "If the parent object is a process instance and that process has
   terminated, get_parent_object shall return either a pointer to the
   surviving process instance or a null pointer if it has been deleted."

 What happens to the object's position itself, when the
 parent object is NULL?

   - It can still be found via sc_find_object( obj.name() )?

   - Is it moved to the top-level, i.e. can it be found via
     sc_get_top_level_objects()?

   - But then basename() != name(), but (since no parent)
     get_parent_object()->name() '.' basename() != name()
     (The name can't be changed, since it is meant to stay valid until
      the object is deleted?)

 This may affect sc_event naming as well.

6.9.2 sc_event_and_expr, sc_event_or_expr definition

  Two free-standing operators missing:

  sc_event_and_expr operator& ( sc_event_and_expr
                              , sc_event_and_list const& );

  sc_event_or_expr operator| ( sc_event_or_expr
                             , sc_event_or_list const& );

6.9.3 Constraints on usage (sc_event_*_expr)

 "The implementation shall delete the event expression object when the
  process instance resumes or is triggered as a direct result of the
  notification of one or more events in the event expression. In
  other words, the implementation shall be responsible for the
  creation, deletion, and memory management of event expression objects
  of type sc_event_and_expr† and sc_event_or_expr†."

 This seems to be a bit imprecise. The event expression object is
 actually a temporary, returned by the final operator in the event
 expression (no pun intended). It is therefore destroyed at the end of
 the full expression (e.g. the call to wait()).

 The thing that is actually managed by the application is the
 creation, deletion and memory management of the returned 'event
 list', via 'operator sc_event_and/or_list const&'.

6.12.5 (sc_port constructors)

  ~sc_port_b(); -> "The destructor shall do nothing."

    Is this restriction needed?

  sc_port();
  sc_port( const char* );

    The sc_port constructors should explicitly pass their template
    parameters N, and P to the constructor of the new sc_port_b base
    class.

6.16.1 sc_object Description (see get_parent_object above)

  "... objects of a class derived from sc_object may be deleted at any
   time. When such an sc_object is deleted, it ceases to be a child."

  If it has child objects itself (in case of a process), what happens
  to their position in the hierarchy? And their names?

  I would even prefer to have a restriction that in case, the "parent"
  object shall not be deleted/invalidated until all children have been
  deleted. But this might break "early invalidating" implementations.

7.30.2/7.30.4 sc_event_queue constructor

  The explicit cast to sc_module_name around the sc_gen_unique_name()
  call is not needed.

9.5.2 sc_vector (class definition)

  sc_vector<T>::size_type is redundant, sc_vector_base::size_type
  should suffice.

  It might be a good idea to make 'sc_vector_iter<T>' a daggered
  name, since one can (and should) always use sc_vector<T>::iterator
  instead.

9.6.5 SystemC Version
11.8.1 TLM version information

  SC_IS_PRERELEASE
  TLM_IS_PRERELEASE

  "... flag shall be either FALSE or TRUE, not enclosed in quotation
   marks."

  Hmmm, maybe 'true' or 'false' (lower-case) would be more portable?
  Or even an application-defined integral constant expression evaluating
  to 0/1 (or false/true).

16.1.2 (tlm_phase)

 Shouldn't the DECLARE_EXTENDED_PHASE macro be called
 TLM_DECLARE_EXTENDED_PHASE? Probably with an backwards-compatible,
 deprecated macro provided by the implementation.

 For consistency with the other macro definitions, a hint that a
 trailing semicolon after the macro is required would be good.

18.1 TLM-1 message passing interfaces

 If objects with non-trivial destructors are passed through the TLM-1
 message passing interfaces, it is important that internal copies are
 properly destroyed when they are no longer "needed".

 Consider the case of a tlm_fifo< shared_ptr<foo> >. It is important,
 that the internal copies in the FIFO are correctly released, after they
 have been taken from the FIFO. This is not explicitly mentioned in the
 description of the interfaces (or in the lifetime section FWIW).
 This is also a bug in the tlm_fifo reference implementation currently.

Annex B, B.58

  "event expression: A list of events, separated by either operator& or
   operator|, and passed as an argument to either the wait or the
   next_trigger method."

  Should be: A list of events or event lists, separated ...

Greetings from Oldenburg,
  Philipp

On 19/11/10 11:23, john.aynsley@doulos.com wrote:
> Folks,
>
> I have uploaded a new draft LRM including sc_vector and sc_writer_policy.
>
> We are now working on just 3 enhancements plus any other minor issues or
> corrections, aiming for completion by the end of November:
>
> * Adding sc_pause and sc_get_status
> * Making request_update thread safe
> * Naming sc_events
>
> Please keep up the energy levels so we can complete each of these by end
> Nov.

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