[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 #20 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #19)

> MAXVL is fixed and known at compile time, not at cpu-design-time.

sorry, we're talking cross-purposes.  at compile-time, yes, however there will
be different MAXVLs for different programs.  i was talking in general about the
fact that SIMD is effectively a hard-fixed MAXVL.

if we were to say "hmm we expect that *most* operations will have a MAXVL of 16
therefore we can create a hard-coded mapreduce network of wires to use for
performing hard-coded 16-long mapreduces" this is not going to fly.

> Adding a microcoded reduce op will allow optimizing for VL which is a
> runtime-variable instead of maxvl, as well as reducing extraneous moves and
> reducing power. Also, a hw-level reduce op could use a 4-way add-reduce ALU,
> kinda like the adder tree part of a wallace tree multiplier.

indeed... and, again: back to comment #13 this requires that the micro-coded
intermediate ops have a storage location for the temporary results.

(putting the temporary results in the regfile is not acceptable)

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.

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