vec_bperm is a challenge for showing an example using just tables,
but I've made an attempt.
Three tables are used:
- The values of the input vectors *a* and *b*.
- A zoomed in view of the last two bytes of *a* and the bit
manipulations therein that leads to the intermediate result.
- The result vector *r*.
Only one example has been provided, but it's getting big.
Fixes#14.
Signed-off-by: Paul A. Clarke <pc@us.ibm.com>
In the absence of sufficient context, the new examples added to:
- vec_double{e,h,l,o}
- vec_permxor
- vec_pmsum_be
- vec_slv
- vec_srv
- vec_sum2s
- vec_sum4s
- vec_sums
- vec_unsigned{e,o}
may appear to be strictly big-endian.
Add headers to these examples showing the element indicies,
which hopefully provides sufficient context.
Fixes#44.
Signed-off-by: Paul A. Clarke <pc@us.ibm.com>
Add simple examples for `vec_unsignede` and `vec_unsignedo`,
making sure to show undefined results and negative truncation.
Fixes#29.
Signed-off-by: Paul A. Clarke <pc@us.ibm.com>
Move the table so that it won't have a head-scratching location
in the HTML view. Update it to add the first_match* and first_mismatch*
functions.
Fixed#39.
Signed-off-by: Bill Schmidt <wschmidt@linux.ibm.com>
The return type for `vec_permxor` which takes `vector signed char`
as inputs should also be `vector signed char`.
Fixes#38.
Signed-off-by: Paul A. Clarke <pc@us.ibm.com>
`vec_permxor` is complex enough to warrant an example.
The table used is very wide. I squeezed it more by changing the names
of `index1` and `index2` to `x` and `y`, respectively.
Note: The table may still be too wide, as some additional warnings are
now generated during `mvn generate-sources`:
```
WARNING: Line 1 of a paragraph overflows the available area by more than 50 points. (See position 1:-1)
Apr 30, 2020 8:44:03 PM org.apache.fop.events.LoggingEventListener processEvent
WARNING: Line 1 of a paragraph overflows the available area by 468 millipoints. (See position 14259:-1)
Apr 30, 2020 8:44:03 PM org.apache.fop.events.LoggingEventListener processEvent
...
WARNING: span="inherit" on fo:block, but no explicit value found on the parent FO.
```
Fixes#20.
Signed-off-by: Paul A. Clarke <pc@us.ibm.com>
vec_vslv and vec_vsrv are confusing in their own right and even more
so because they operate only with big-endian semantics.
Some examples are warranted.
Note that the respective examples are arranged such that the impact of
shifting in zero bits has a visible impact.
Signed-off-by: Paul A. Clarke <pc@us.ibm.com>
Paul Clarke
Bill Schmidt