<br><font size=2 face="sans-serif">Uzi, I don't think we're proposing to
change the existing default behavior, so the clock provided by the library
will continue to represent wall time by default. Any new behavior
would be optional.</font>
<br>
<br><font size=2 face="sans-serif">I like the idea of maintaining both
the wall time and a delta. This would allow us to provide both real
time (for trace timestamps) and virtual time (for measurements/timers)
at the same time with the library.</font>
<br><font size=2 face="sans-serif"><br>
Dean Burdick<br>
Cell Software Development<br>
IBM Austin, TX<br>
512-838-0264 T/L: 678-0264<br>
</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>Arnd Bergmann <arnd@arndb.de></b>
</font>
<p><font size=1 face="sans-serif">10/22/2007 08:47 AM</font>
<td width=59%>
<table width=100%>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td><font size=1 face="sans-serif">Uzi Shvadron <SHVADRON@il.ibm.com></font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td><font size=1 face="sans-serif">cbe-oss-dev@ozlabs.org, Dean Burdick/Austin/IBM@IBMUS</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td><font size=1 face="sans-serif">Re: [Cbe-oss-dev] Fwd: adding virtual
SPU timers</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><tt><font size=2>On Monday 22 October 2007, Uzi Shvadron wrote:<br>
<br>
> > On Monday 15 October 2007, Arnd Bergmann wrote:<br>
> > ><br>
> > > Also, I'd like to hear what kind of requirement other people<br>
> > > have so we can do the right thing and don't need another
special<br>
> > > workaround for a specific use of the timers.<br>
><br>
> The SPU time base should be a system resource as the PPE time base
is. That<br>
> is, it should run freely and be accessed by an API such as the spu-timer<br>
> API.<br>
> In order to provide a time value the spu-timer should always be active
and<br>
> provide a 64 bits increment clock. This comes along with another idea
to<br>
> provide a small service kernel on the SPUs. This kernel may provide
a set<br>
> of services and environment variables to the applications. One of
these<br>
> services would be the spu-timer API. I know this opens the stage to
larger<br>
> discussion and there is a need to defined set of requirements. Note
though<br>
> that the above issues may lead to such solution. If such a kernel
is<br>
> created there will be no need to deal with the timer at the Linux
kernel<br>
> level.<br>
<br>
I don't think we can get to the point where everybody agrees on a<br>
common runtime environment beyond what is provided with libc, but it sounds<br>
fair to have an (optional) library abstracts the use of the decrementer<br>
in the same way that we have libraries for managing overlays and MFC tags.<br>
<br>
The way you describe where you want to end up sounds like it would conflict<br>
with Dean's work, as it suggests that that there needs to be a source for<br>
real time instead of the 'virtual time' that Dean was asking for.<br>
<br>
Arnd <><<br>
</font></tt>
<br>