P1666 review issues from Alan

Alan,

Here is my response to your review issues, excluding those issues for
which I consider further discussion is definitely required. Of course, you
are free to dispute the issues below where I consider no change is
required.

My comments are marked [JA] below

John A

page 5
For consistency, should there be a definition of the event hierarchy?

[JA] Under the term "object hierarchy" I will explain that events do not
belong to the object hierarchy, even though they may have a hierarchical
name.

Section 4.1 says
"The term during elaboration or simulation includes every phase from the
construction of the module hierarchy up to and including the final delta
cycle."

However Section 5 point h) says simulation includes destruction of the
module hierarchy,
i.e. after the final delta cycle.

[JA] Deliberately so. I do not see any contradiction here. I spent a lot
of time analyzing the usage of these terms throughout the LRM. The defn in
4.1.4 does not exclude destructor calls. I will spell this out in 4.1.4

In section 5.2, does the paragraph starting "The scheduler can execute a
spawned or unspawned process..." need updating due to the introduction of
the new process
control functions?

[JA] Yes. Good catch. Done.

Section 5.4.4 item d) notify should be notify() for consistency with
section 5.4.3 item g)
See also section 5.5.2 item d)

[JA] Yes, good point. notify() was meant to imply an empty argument list,
but it would be better to say that explicitly. I'll change it.

Section 5.5.3. I don't understand the sentences
"Function sc_set_stop_mode may be called during elaboration or from one
of the callbacks before_end_of_elaboration, end_of_elaboration, or
start_of_simulation. It shall be an error to call function
sc_set_stop_mode from the scheduler other than from one of these three
callbacks."

Why say "Function sc_set_stop_mode may be called during elaboration *or*
..." then say it is an error to call the function outside the three
named callbacks? Isn't the clause before the *or* redundant?

[JA] I agree! Not sure what I was thinking that day. I will change the
wording.

p56 table 1
"start_of_simuluation" should be
"start_of_simulation"
"end_of_simuluation" should be
"end_of_simulation"

[JA] Done.

p56
This sentence
"When called from before_end_of_elaboration, sc_get_status shall return
SC_BEFORE_END_OF_ELABORATION even when called from the constructor of a
module (or other object) called directly or indirectly
frombefore_end_of_elaboration."

didn't read properly to me? Should there be an "or" in front of "called
directly"?

[JA] Agreed. Re-written.

section 6.1.1
Does header file systemc now add sc_unnamed as well?
Similarly 6.1.2

[JA] Agreed. Changed.

Section 6.2.21
Would it be worth adding a note describing why get_child_events exists?
I.e. why it was decided that sc_events are not derived from sc_object?
Also perhaps a note needs adding to 6.3.4 - in Note 1 it talks about the
"object hierarchy" - but I think this excludes sc_event i.e. "object
hierarchy" is only referring to classes derived from
sc_object

[JA] I will add notes pointing out that events too have a hierarchical
name, though they are not part of the object hierarchy.

6.8.2
The "=" signs in the member function declarations don't look bold.

[JA] I think they are?

6.12.2
The indentation of
   virtual void bind(IF&);
is broken.

[JA] Agreed. Fixed.

7.4.2
There isn't a description of the function
virtual sc_writer_policy get_writer_policy() const;
Though I've realised there is in section 7.3.3, but 7.3.3 doesn't
actually say what get_writer_policy() should do in a derived class
(though it's obvious it should return the value of the template argument).

[JA] Agreed. Added.

7.5.3
refers back to the member function definitions in 7.4, but there isn't
one for get_writer_policy()
But see 7.3.3.

[JA] Agreed. There is now.

9.2.4
"indicitive" should be
"indicative"

[JA] Agreed. Fixed.

9.5.9
"refered" should be
"referred"

[JA] Agreed. Fixed.

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