<br><tt><font size=2>&gt; On Tuesday 29 May 2007, Brian Watt wrote:<br>
&gt; &gt; OK. I think I understand.<br>
&gt; <br>
&gt; I think you don't ;-)<br>
&gt; <br>
&gt; &gt; &gt; The registers are only accessible in saved state, so in
order to<br>
&gt; &gt; &gt; change them, the context needs to be suspended and written
back<br>
&gt; &gt; &gt; into kernel memory.<br>
&gt; &gt; <br>
&gt; &gt; That is fine, because I have no need to modify the registers
while the <br>
&gt; &gt; context is executing. Instead I would only need to update the
registers <br>
&gt; &gt; when the context is in a saved state prior to execution. Then
the context <br>
&gt; &gt; would be executed which would execute the SPE program until it
returns <br>
&gt; &gt; (though a completion stop and signal, 0x2000) whereby I assume
the context <br>
&gt; &gt; is suspended and written back - therefore in a saved state. After
this the <br>
&gt; &gt; registers could be read to get the results, and the process would
repeat <br>
&gt; &gt; itself for the next call again by setting up the registers. So
maybe I'm <br>
&gt; &gt; not understanding what the issue is that you are trying to explain
to me, <br>
&gt; &gt; because I think the context is in the correct state as you suggest.<br>
&gt; <br>
&gt; There are four different states that a context can be in:<br>
&gt; <br>
&gt; 1. saved and idle<br>
&gt; 2. saved and trying to run<br>
&gt; 3. loaded and running<br>
&gt; 4. loaded and idle<br>
&gt; <br>
&gt; Initially, it is in state 1, where you can easily modify the registers.<br>
&gt; When you call spe_context_run, it goes through state 2 in the scheduler<br>
&gt; to state 3, where it actually executes code.<br>
&gt; <br>
&gt; When it returns by the means of stop-and-signal, and there is no other<br>
&gt; context in state 2, it will be in state 4, waiting to be called again.<br>
&gt; This is an important performance optimization. When you call<br>
&gt; spe_context_run the next time, it can quickly go from state 4 to state
3<br>
&gt; again, without ever having to be saved into memory.<br>
&gt; <br>
&gt; Accessing the registers of a loaded context forces it to be saved
into<br>
&gt; state 1 or 2, and then loaded again as it tries to run.<br>
&gt; <br>
&gt; &nbsp; &nbsp;Arnd &lt;&gt;&lt;<br>
</font></tt>
<br><tt><font size=2>Thanks Arnd, that was excellent, and yes, I didn't
fully understand</font></tt>
<br><tt><font size=2>the states. So what I take away is to keep the context
moving from</font></tt>
<br><tt><font size=2>loaded and idle to loaded and running is the best.
And to do that</font></tt>
<br><tt><font size=2>I should not use registers, but rather communicate
through local</font></tt>
<br><tt><font size=2>store. Is this correct?</font></tt>