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

bugzilla-daemon at libre-soc.org bugzilla-daemon at libre-soc.org
Mon Dec 14 17:58:14 GMT 2020


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

--- Comment #42 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to cand from comment #40)
> I remembered where IBM's example is probably from, databases. There you
> could find a stream of 7-bit ints. VSX would need adjusting between every

interesting.

i must apologise, i think i was looking for a different VSX instruction, one
where, unlike rldimi, the shift and mask data were taken from a register:

   sh = RA[0..7]
   mask = (1<<RA[8..15]) -1

   RT |= (RB & mask) << sh

that sort of thing.  that's a last resort, i'd prefer an immediate but if it
needs greater than say 12 bits then a register it has to be.

if however you are saying that even trying general purpose pixel-extraction is
not worth it (to support arbitrary future pixel encodings like 10 10 10, or...
i don't know) then i am happy to drop this.

one possibility though, just specify the start points (in bits) relative to
each other, then follow up with a separate mask and shift op

    vec.extract(5 6 5)
    AND with immediate
    shift

the idea being here, the vec.extract takes:

* first 5 bits and places it in ra
* next 6 bits and places in ra+1
* next 5 into ra+2

a followup shift will move those up into the MSBs, the 5 shifted by 3, 6 by 2.

then if you want 10 10 10 the same thing must be done, except there it would be
10 10 10 discard2

now, as long as the massive 256+ bit SR can be told, "move everything along by
8 16 24 32 48 64" and still be useful, then i'm ok with that.

i *believe* it would do the job, to be able to have arbitrary sized data
dropped in and out of it, but if we try going to a shift granularity of 1 bit
on something that long it's going to get hairy.

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


More information about the libre-soc-bugs mailing list