The v2 branch was used to work on PVIPR v2.0 while PVIPR v1.0 was
still under review. Since PVIPR 1.0 has now been published, and a
separate document will be used for v1.0 errata, merge v2 into mainline
and use mainline for further updates.
Change occurrences of "An example follows" to
"An example for input _i_ of type _t_ follows",
in cases where an intrinsic has more than one possible input type.
Signed-off-by: Paul A. Clarke <pc@us.ibm.com>
Add examples for
- `vec_first_match_index`
- `vec_first_match_index_or_eos`
- `vec_first_mismatch_index`
- `vec_first_mismatch_index_or_eos`
Also, `vec_first_match_index` implmentations in this document and
in GCC were behaving like `vec_first_match_or_eos_index`.
Correct this document. GCC PR94833 was already opened.
Fixes#18.
Signed-off-by: Paul A. Clarke <pc@us.ibm.com>
- Explicitly mention that there are no default conversions.
- Clarify that binary operations are on like types.
- Clarify requirements for the ternary operator and add an example.
Asserting that the clarified content is clear enough,
Fixes#11.
Signed-off-by: Paul A. Clarke <pc@us.ibm.com>
Since there isn't a straightforward way of initializing `__int128` type
variables, provide an example for initializing `vector __int128` here.
Fixes#10.
Signed-off-by: Paul A. Clarke <pc@us.ibm.com>
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>
Bill Schmidt
Toshaan Bharvani
Paul Clarke