volk_cpu.tmpl.c on non-X86 cpus

[michael-roe]

Looking at the code, it treats anything starting with "neon" as an ARM feature, and everything else as x86.

I haven't tried running it yet, but I think this will break when run on any architecture that isn't ARM or X86.

(I am going to upstream some MIPS fixes to cpu_features, and I have several different MIPS workstations to test on. If I have time and I'm feeling brave enough, I might try writing a RISC-V port of CPU features.)

I think we may need a more general mechanism to say which features are part of which architecture.

=======

there's another problem with the code in this file. It assumes that the total number of cpu features, across all architectures, is less than or equal to the number of bits in an int. This is so it can set a bit in an int for each feature. This is not going to scale when volk is ported to more architectures. A bit for each feature of the architecture it's been compiled for would fit. A bit for every feature of every architecture volk has been ported to will eventually not fit.

[jdemel]

https://github.com/gnuradio/volk/blob/af69c60e908cd64b3bacd4ee6b4ce4a52b711865/tmpl/volk_cpu.tmpl.c#L101-L108

I had a closer look at your second comment. I assume you refer to the volk_get_lvarchfunction. It is only used involk.c`, e.g.

https://github.com/gnuradio/volk/blob/af69c60e908cd64b3bacd4ee6b4ce4a52b711865/tmpl/volk.tmpl.c#L48

It is related to this field: https://github.com/gnuradio/volk/blob/af69c60e908cd64b3bacd4ee6b4ce4a52b711865/tmpl/volk_machines.tmpl.h#L34

Currently, numbers up to 23 are used. This implies that 23 bit are used. It'd be better to start looking for a better solution here.

[jdemel]

Since we use cpu_features with MIPS etc. now, and things still work, I suggest to close this issue.