[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