DSP optimization

[Sylvain Munaut]

Hi,

> This was the issue I was trying to raise. The patch (that doesn't
> exist) for the API change on osmo-bts alone is huge. I don't like any
> API breaking changes, and I have limited interest in making changes to
> osmo-bts. I do like compatibility layers though.

Yes, both adapting the code and/or adding compatibility layer are no issue.

Ideally the code should just end up in libosmocore, (being compiled if
supported), and
just "work" with any code that previously worked, possibly fallbacking
to the reference
impl at runtime if something weird is not supported.

And all in all be completely transparent to the user, just
accelerating it if possible.



>> Also, it should be obvious but any change in libosmocore must stay
>> compatible with all codes that have been supported until now and not
>> just a subset of GSM/LTE specific codes.
>
> Aside from testing all the various combinations, I'm less concerned
> about structural (non-API) compatibility. The convolutional codes are
> defined by the trellis structure or, equivalently, shift register and
> generator polynomials. The Viterbi algorithm is fundamentally the same
> in all cases. Unless there are some truly bizarre cases, which you
> would know more about than I do, I see this as less of an issue.

The treillis scan is very similar in all cases. The only thing to
support is the puncturing during the scan (I wanted to avoid having
the de-puncture first).
It also currently supports progressive decoding (i.e. you can start
decoding a message before you have all of it if you want, you just
feed it chunk by chunk and it can resume where it left off).

Most of the changes between variations come from the way the
termination is handled but since that's always only a few symbols,
that could be left alone unoptimized (assuming the internal state is
compatible enough).


Cheers,

     Sylvain