[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 #38 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
right. ok.  so if there's this Monster FSM with 12 incoming operands and 12
outgoing ones (minimum) and at its core is a Shift Register then performing
*basic* expansion and selection is not unreasonable.  addition and ORing is
probably ok (multiply is almost certainly not).

if you can come up with some sort of algorithm, perhaps involving
shift-and-mask that also takes the current SUBVL index into account, then it
may be worthwhile deploying.  the algorithm should involve the *one* pixel (but
take into account SUBVL)

one idea to get encoding space down: specify whether the selected bits are
shifted up to the MSB or left in the LSB.

the basic idea here is to see what it takes to efficiently cover as wide a
range of bit-based pack/unpack operations.  if we absolutely have to then the
pack/unpack data should be in another register (like vector-shift
left-variable, p265 v3.0B)

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