VOLK C++ core

[Johannes Demel]

Hi everyone,

today I'd like to propose an idea for the future of VOLK. Currently, 
VOLK is a C library with a C++ interface and tooling that is written in C++.

I propose to make VOLK a C++ library. Similar to e.g. UHD, we can add a 
C interface if the need arises.

This email serves as a request for comments. So go ahead.

Benefits:
- sane std::complex interface.
- same compilation mode on all platforms.
- Better dynamic kernel load management.
- Option to use std::simd in the future
- Less manual memory management (think vector, ...).

Drawbacks:
- It is a major effort.
- VOLK won't be a C project anymore.

Why do I propose this shift?
VOLK segfaults on PowerPC architectures. This issue requires a breaking 
API change to be fixable. I tried to update the API to fix this isse.
https://github.com/gnuradio/volk/pull/488
It works with GCC and Clang but fails on MSVC.
One might argue that PowerPC is an obscure architecture at this point 
but new architectures might cause the same issue in the future. Also, 
VOLK tries to be portable and that kind of issue is a serious roadblock.

How did we get into this mess?
The current API is a workaround to make things work for a specific 
compiler: MSVC. MSVC does not support C `complex.h` at all. The trick to 
make things work with MSVC is: compile VOLK in C++ mode and pretend it 
is a C++ library anyways.
In turn `volk_complex.h` defines complex data types differently 
depending if VOLK is included in C or C++. Finally, we just hope that 
the target platform provides the same ABI for C complex and C++ complex. 
C complex and C++ complex are not compatible. However, passing pointers 
around is.
Thus, the proposed change does not affect Windows/MSVC users because 
they were excluded from our C API anyways. The bullet point: "same 
compilation mode on all platforms" refers to this issue.

Proposed timeline:
Together with our re-licensing effort, we aim for a VOLK 3.0 release. 
VOLK 3.0 is a good target for breaking API changes.

Effects:
I'd like to make the transition to VOLK 3.0 as easy as possible. Thus, 
I'd like to keep an interface that hopefully doesn't require any code 
changes for VOLK 2.x users. A re-built of your application should be 
sufficient. However, we'd be able to adopt a C++-ic API as well. e.g. 
use vectors, spans etc.

The current implementation to detect and load the preferred 
implementation at runtime is hard to understand and easy to break. C++ 
should offer more accessible tools to make this part easier.

What about all the current kernels?
We'd start with a new API and hide the old kernel code behind that 
interface. We come up with a new implementation structure and how to 
load it. Thus, we can progressively convert to "new-style" implementations.

Another bonus: std::simd
Currently, std::simd is a proposal for C++23. Making VOLK a C++ lib 
would allow us to eventually use std::simd in VOLK and thus make Comms 
DSP algorithms more optimized on more platforms.

Cheers
Johannes