Earlier quoted context omitted.
I don't know what you want of the VSX, but if you want vectorized code, what do you expect to gain over letting the compiler do it on your C? If you want an example, there's the kernels in OpnBLAS and FFTW (and BLIS, but that seems to be broken on POWER9). There's an IBM web page somewhere with three(?) alternatives for using VSX, one of which is just using SSE intrinsics -- I don't know how well that works -- and an…
What I’d like to do is a quick proof-of-concept to see whether whatever instructions are available in my CPU can be leveraged for UTF-8 en-/decoding. For instance, does it work any better than my C implementation? https://github.com/Sentido-Labs/cedro/blob/master/src/cedro.... Maybe the compiler already compiles that to an optimal SIMD version, I don’t know. That’s what I would like to find out. And if the VSX instru…
A better way would be to explicitly use the newer mtvsrd (mtfprd) and mfvsrd (mffprd) instructions and avoid the spill. So here's a revision 2.
#include
#include
#include
#include
int main(int argc, char **argv) {
uint64_t v = 0;
if (argc != 2) {
fprintf(stderr, "usage: %s quantity\n", argv[0]);
return 1;
}
v = strtoull(argv[1], NULL, 0);
if (errno == EINVAL || errno == ERANGE) {
perror("strtoull");
return 1;
}
__asm__(
"mtfprd %1, %0\n"
"xxbrd %1, %1\n"
"mffprd %1, %0\n"
:"=r"(v)
:"r"(v)
);
fprintf(stdout, "0x%lx\n", v);
return 0;
}
If v is already in a register, then it can just stay there.