- 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>
The "Vector Registers as Part of VSRs" figure was very large,
especially as it immediately follows an almost identical figure.
Before this change:
fig-fpr-vsr.png: PNG image data, 663 x 300...
fig-vr-vsr.png: PNG image data, 1367 x 608...
After this change:
fig-fpr-vsr.png: PNG image data, 663 x 300...
fig-vr-vsr.png: PNG image data, 645 x 287...
I chose this size because the actual side boundaries of the
table most closely match in size.
The scaling, using The GIMP, resulted in somewhat blurry lines,
but still quite clear enough, and good enough.
Signed-off-by: Paul A. Clarke <pc@us.ibm.com>
Bill Schmidt
Paul Clarke