pseudocode: [[openpower/isa/bitmanip]]
-this extension amalgamates bitmanipulation primitives from many sources, including RISC-V bitmanip, Packed SIMD, AVX-512 and OpenPOWER VSX.
-Also included are DSP/Multimedia operations suitable for
-Audio/Video. Vectorisation and SIMD are removed: these are straight scalar (element) operations making them suitable for embedded applications.
-Vectorisation Context is provided by [[openpower/sv]].
-
-When combined with SV, scalar variants of bitmanip operations found in VSX are added so that the Packed SIMD aspects of VSX may be retired as "legacy"
-in the far future (10 to 20 years). Also, VSX is hundreds of opcodes, requires 128 bit pathways, and is wholly unsuited to low power or embedded scenarios.
-
-ternlogv is experimental and is the only operation that may be considered a "Packed SIMD". It is added as a variant of the already well-justified ternlog operation (done in AVX512 as an immediate only) "because it looks fun". As it is based on the LUT4 concept it will allow accelerated emulation of FPGAs. Other vendors of ISAs are buying FPGA companies to achieve similar objectives.
-
-general-purpose Galois Field 2^M operations are added so as to avoid huge custom opcode proliferation across many areas of Computer Science. however for convenience and also to avoid setup costs, some of the more common operations (clmul, crc32) are also added. The expectation is that these operations would all be covered by the same pipeline.
-
-note that there are brownfield spaces below that could incorporate some of the set-before-first and other scalar operations listed in [[sv/vector_ops]], [[sv/int_fp_mv]] and
-the [[sv/av_opcodes]] as well as [[sv/setvl]], [[sv/svstep]], [[sv/remap]]
+this extension amalgamates bitmanipulation primitives from many sources,
+including RISC-V bitmanip, Packed SIMD, AVX-512 and OpenPOWER VSX.
+Also included are DSP/Multimedia operations suitable for Audio/Video.
+Vectorisation and SIMD are removed: these are straight scalar (element)
+operations making them suitable for embedded applications. Vectorisation
+Context is provided by [[openpower/sv]].
+
+When combined with SV, scalar variants of bitmanip operations found in
+VSX are added so that the Packed SIMD aspects of VSX may be retired as
+"legacy" in the far future (10 to 20 years). Also, VSX is hundreds of
+opcodes, requires 128 bit pathways, and is wholly unsuited to low power
+or embedded scenarios.
+
+ternlogv is experimental and is the only operation that may be considered
+a "Packed SIMD". It is added as a variant of the already well-justified
+ternlog operation (done in AVX512 as an immediate only) "because it
+looks fun". As it is based on the LUT4 concept it will allow accelerated
+emulation of FPGAs. Other vendors of ISAs are buying FPGA companies to
+achieve similar objectives.
+
+general-purpose Galois Field 2^M operations are added so as to avoid
+huge custom opcode proliferation across many areas of Computer Science.
+however for convenience and also to avoid setup costs, some of the more
+common operations (clmul, crc32) are also added. The expectation is
+that these operations would all be covered by the same pipeline.
+
+note that there are brownfield spaces below that could incorporate
+some of the set-before-first and other scalar operations listed in
+[[sv/vector_ops]], [[sv/int_fp_mv]] and the [[sv/av_opcodes]] as well as
+[[sv/setvl]], [[sv/svstep]], [[sv/remap]]
Useful resource:
# binary and ternary bitops
Similar to FPGA LUTs: for two (binary) or three (ternary) inputs take
-bits from each input, concatenate them and
-perform a lookup into a table using an 8-8-bit immediate (for the ternary instructions), or in another register (4-bit
-for the binary instructions). The binary lookup instructions have CR Field
-lookup variants due to CR Fields being 4 bit.
+bits from each input, concatenate them and perform a lookup into a
+table using an 8-8-bit immediate (for the ternary instructions), or in
+another register (4-bit for the binary instructions). The binary lookup
+instructions have CR Field lookup variants due to CR Fields being 4 bit.
-Like the x86 AVX512F [vpternlogd/vpternlogq](https://www.felixcloutier.com/x86/vpternlogd:vpternlogq) instructions.
+Like the x86 AVX512F
+[vpternlogd/vpternlogq](https://www.felixcloutier.com/x86/vpternlogd:vpternlogq)
+instructions.
## ternlogi
required for the [[sv/av_opcodes]]
-signed and unsigned min/max for integer. this is sort-of partly synthesiseable in [[sv/svp64]] with pred-result as long as the dest reg is one of the sources, but not both signed and unsigned. when the dest is also one of the srces and the mv fails due to the CR bittest failing this will only overwrite the dest where the src is greater (or less).
+signed and unsigned min/max for integer. this is sort-of partly
+synthesiseable in [[sv/svp64]] with pred-result as long as the dest reg
+is one of the sources, but not both signed and unsigned. when the dest
+is also one of the srces and the mv fails due to the CR bittest failing
+this will only overwrite the dest where the src is greater (or less).
signed/unsigned min/max gives more flexibility.
# bitmask set
based on RV bitmanip singlebit set, instruction format similar to shift
-[[isa/fixedshift]]. bmext is actually covered already (shift-with-mask rldicl but only immediate version).
-however bitmask-invert is not, and set/clr are not covered, although they can use the same Shift ALU.
+[[isa/fixedshift]]. bmext is actually covered already (shift-with-mask
+rldicl but only immediate version). however bitmask-invert is not,
+and set/clr are not covered, although they can use the same Shift ALU.
-bmext (RB) version is not the same as rldicl because bmext is a right shift by RC, where rldicl is a left rotate. for the immediate version this does not matter, so a bmexti is not required.
-bmrev however there is no direct equivalent and consequently a bmrevi is required.
+bmext (RB) version is not the same as rldicl because bmext is a right
+shift by RC, where rldicl is a left rotate. for the immediate version
+this does not matter, so a bmexti is not required. bmrev however there
+is no direct equivalent and consequently a bmrevi is required.
bmset (register for mask amount) is particularly useful for creating
predicate masks where the length is a dynamic runtime quantity.
-bmset(RA=0, RB=0, RC=mask) will produce a run of ones of length "mask" in a single instruction without needing to initialise or depend on any other registers.
+bmset(RA=0, RB=0, RC=mask) will produce a run of ones of length "mask"
+in a single instruction without needing to initialise or depend on any
+other registers.
| 0.5|6.10|11.15|16.20|21.25| 26..30 |31| name |
| -- | -- | --- | --- | --- | ------- |--| ----- |
}
```
-bitmask extract with reverse. can be done by bit-order-inverting all of RB and getting bits of RB from the opposite end.
+bitmask extract with reverse. can be done by bit-order-inverting all
+of RB and getting bits of RB from the opposite end.
when RA is zero, no shift occurs. this makes bmextrev useful for
simply reversing all bits of a register.
grevlut should be arranged so as to produce the constants
needed to put into bext (bitextract) so as in turn to
-be able to emulate x86 pmovmask instructions <https://www.felixcloutier.com/x86/pmovmskb>.
+be able to emulate x86 pmovmask instructions
+<https://www.felixcloutier.com/x86/pmovmskb>.
This only requires 2 instructions (grevlut, bext).
Note that if the mask is required to be placed
as GF2P8AFFINEQB. uses:
* <https://gist.github.com/animetosho/d3ca95da2131b5813e16b5bb1b137ca0>
-* SM4, Reed Solomon, RAID6 <https://stackoverflow.com/questions/59124720/what-are-the-avx-512-galois-field-related-instructions-for>
+* SM4, Reed Solomon, RAID6
+ <https://stackoverflow.com/questions/59124720/what-are-the-avx-512-galois-field-related-instructions-for>
* Vector bit-reverse <https://reviews.llvm.org/D91515?id=305411>
* Affine Inverse <https://github.com/HJLebbink/asm-dude/wiki/GF2P8AFFINEINVQB>
projects / libreriscv.git / commitdiff