I am proposing that we define clock ID 0 as referring to the implicit
1/1 cclock.  This would allow a transactor to control the implicit
cclock.  Controlling the implicit cclock could be useful if the
transactor wanted to stop the clocks immediately rather than at the
next rising edge of some slow cclock it is using.

Per

==============================================================================


We have found that the simplest user semantics for clock stoppage are
that stopping ANY clock stops the underlying 1/1 cclock. We therefore
propose that this become the semantics for stopping any clock.   Of course
we would have to discuss backwards compatibility for current implementations
which take advantage of the current "slide to a halt" semantics.

Duaine

=============================================================================

Just for my clarification, you are proposing to move away from the
`just-in-time' semantics that is in 1.0?  The new semantics would
be `stop-right-now-(almost)' semantics, right?  (The `almost' is to
cover the case that the 1/1 cclock is slower than uclock).

> DWP=> Yes.

I have no problem with this.  It would have the added benefit of
simplifying clock control implementation.  As for backwards
compatibility, perhaps we can add a new parameter to the clock
control macro that selects the semantics and have its default
value be the `just-in-time' semantics?

When using the new semantics the ClockNum parameter of the
SceMiClockControl macro is no longer necessary, right?

Per