this looks perfect:
this is where it goes awry.
whilst the Compliancy Levels make VSX entirely optional, even at the Embedded FP level, it's the V2 ABI which forces VSX.
found contact details for bill schmidtt
if we can, we should try to use the v2 abi without altivec since it also has many other improvements.
*vsx is actually a misnomer when applied to powerpc's SIMD support in general*, it refers specifically to the new vector-scalar interop instructions added in POWER9 (or 8? icr), not to SIMD in general, we should use either altivec or SIMD as terms that people will recognize otherwise we may get software support for SIMD without vsx -- not the intended endpoint.
(In reply to Jacob Lifshay from comment #4)
> if we can, we should try to use the v2 abi without altivec since it also has
> many other improvements.
> *vsx is actually a misnomer when applied to powerpc's SIMD support in
> general*, it refers specifically to the new vector-scalar interop
> instructions added in POWER9 (or 8? icr), not to SIMD in general, we should
> use either altivec or SIMD as terms that people will recognize otherwise we
> may get software support for SIMD without vsx -- not the intended endpoint.
vmx is also an acceptable term for altivec:
this turns out not to be true (many thanks to steve, author of pveclib)
there *is* an ABI, it is currently v2.0 soon to be v2.1, and VSX
*is* optional, as are many other things that suit SFFS and SFS
steve kindly explained to me that going back to v1.4 for example
would be a serious mistake, as there were a *lot* of issues fixed.
it also turns out to be straightforward to pass
the options to today's gcc to get it to disable
VSX and 128-bit FP: https://bugs.libre-soc.org/show_bug.cgi?id=1131#c1