[Libre-soc-bugs] [Bug 230] Video opcode development and discussion

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=230

--- Comment #23 from Cole Poirier <colepoirier at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #22)
> (In reply to Cole Poirier from comment #21)
> 
> > > thinking that through is an exercise that i have done many times.  all
> > > designs involving temporary result storage require far more complexity than
> > > i am comfortable with committing to within an already heavily pressured
> > > timeframe where we are at least 8 months behind where we should be.
> > 
> > Would scratch-pad memories be applicable in this instance?
> 
> probably depends on the context for which you're thinking scratchpad
> memories might be useful.
> 
> if they are for a single dedicated purpose, for use by one thread and one
> thread only, then they need not be protected by context-switching or
> anything at all.

This is indeed what I was thinking of.


> any such scratchpad memory, if considered for use for the explicit purpose
> of context-switching (to save for example the above-mentioned "temporary
> registers") then its designation actually switches from "scratchpad memory"
> to "a type of register file".  which we already said isn't ok to add,
> because of the complexity it introduces in its management during
> context-switching.

Was not thinking of this, I don't have an idea of how to solve the
context-switching state preservation issue of 1000 long operations. Yes indeed,
preservation across context switch is reg file not scratch pad.

> the other option is to throw away the entirety of the micro-op up until that
> point, and restart it once the context-switch returns.  i dislike these
> types of wasteful "solutions".... and, again, they actually have to have
> resources dedicated to implementing them.

In a multi-core system would it be possible to assign such long-running
operations to a single core non-preemptably except for interrupts? That would
possibly have such operations run to completion on a majority of attempts, but
still respect system interrupt priority.

> *whatever* is proposed, there will be an evaluation cost, a design cost, an
> implementation cost and a testing cost.
>
> we do not have time for that on something that we have no input yet as to
> whether it is 1% used, 10% used or 30% used.

Ahh, went and re-read the bug report. I thought this was something that needed
a solution in order to proceed, I remembered after refreshing my memory through
re-reading the bug that this is essentially an enhancement with great cost
associated with it. Discard my comments.

-- 
You are receiving this mail because:
You are on the CC list for the bug.