EBNO pull request

[jeroenbeijer]

Hi Again,

New pull request. I needed to keep the burst MSK EBNO averaging time very short to allow the R packets to fit in there and show EBNO for this in time. However I realized that the time I set earlier was longer than the number of samples that would have been in there by the time it was sent to the mainwindow. So i lowered the averaging time a little so it matches better with when the EBNO is sent. Hope that makes sense. Also removed the libcorrect artifacts.

/Jeroen

[jontio]

The problem with removing libcorrect.a and libcorrect.dll.a is that if someone is using qt with a static build on windows then they have to build libcorrect to create these two files. I've noticed when I did a static build I still needed liibcorrect.dll at run time.

[jeroenbeijer]

You mean a full static QT build resulting in a single jaero.exe without any supporting dll's or statically linking only libcorrect into jaero.exe? I have done the latter using the library file in which case I did not need the dll at runtime.

[jontio]

Sort of the first but not entirely. In MSYS2 there are two packages (mingw-w64-i686-qt5-static 5.9.2-2 and mingw-w64-x86_64-qt5-static 5.9.2-2) that produce static builds without using qt dlls and these require the dll.a and .a files of libcorrect. That then compiles and links but even then you still need the libcorrect dll at runtime. This I'm finding more handy for packaging as I don't have to worry about the qt plugins and dlls.

[jeroenbeijer]

Ok I see what you mean but odd that one would need the dll at runtime if it has all been statically linked. Shall I add them back in? One thing worth noting is that I slightly modified the libcorrect code to make it run on my (older but not that old) PC/CPU. I think more people will run into this issue when running with the latest libcorrect without this minor change.

[jontio]

Yes odd. I can put them back in. I'm having a look today at the range of the soft bits so not problems.

What are the changes you made to libcorrect?

[jeroenbeijer]

The original libcorrect uses popcount which is an SSE4 instruction that I think a good number of "older" CPU's will not support. It counts the number of bits set to 1. I have replaced it with an inline method that achieves the same result. Not sure what the performance impact is.

https://en.wikipedia.org/wiki/SSE4

Example: for (size_t j = 0; j < rate; j++) { out |= (popcount(i & poly[j]) % 2) ? mask : 0; mask <<= 1; }

Replaced popcount with:

inline int count_setbits(int N) { int cnt=0; while(N>0) { cnt+=(N&1); N=N>>1; } return cnt; }

[jontio]

i noticed in libcorrect/include/correct/portable.h is says...

#ifdef __GNUC__
#define HAVE_BUILTINS
#endif

#ifdef HAVE_BUILTINS
#define popcount __builtin_popcount
#define prefetch __builtin_prefetch
#else

static inline int popcount(int x) {
    /* taken from the helpful http://graphics.stanford.edu/~seander/bithacks.html#CountBitsSetParallel */
    x = x - ((x >> 1) & 0x55555555);
    x = (x & 0x33333333) + ((x >> 2) & 0x33333333);
    return ((x + (x >> 4) & 0x0f0f0f0f) * 0x01010101) >> 24;
}

static inline void prefetch(void *x) {}

#endif

So if GNUC and HAVE_BUILTINS arn't defined then it uses this function for the bit count.

If GNUC is defined as it should be with mingw then mingw should have a function called __builtin_popcount. I would have thought if a computer didn't support popcnt then mingw would do something like the above. Typeing cat /proc/cpuinfo | grep sse3 for me produces ...

flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 movbe popcnt xsave osxsave rdrand lahf_lm arat epb xsaveopt pln pts dtherm fsgsbase tsc_adjust erms invpcid
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 movbe popcnt xsave osxsave rdrand lahf_lm arat epb xsaveopt pln pts dtherm fsgsbase tsc_adjust erms invpcid

So I see popcnt written there. I'm not sure how I would tell the build process to use the inline function. I find anything but qmake really confusing. Anyway I'll define DONE_USE_BUILTINS and modify portables.h to read ...

#ifdef __GNUC__
#define HAVE_BUILTINS
#endif

#if defined(HAVE_BUILTINS) && !defined(DONT_USE_BUILTINS)
#define popcount __builtin_popcount
#define prefetch __builtin_prefetch
#else

static inline int popcount(int x) {
    /* taken from the helpful http://graphics.stanford.edu/~seander/bithacks.html#CountBitsSetParallel */
    x = x - ((x >> 1) & 0x55555555);
    x = (x & 0x33333333) + ((x >> 2) & 0x33333333);
    return ((x + (x >> 4) & 0x0f0f0f0f) * 0x01010101) >> 24;
}
static inline void prefetch(void *x) {}

#endif

That sound do the trick.

I get warnings suggest parentheses around '+' in operand of '&' for the inline function. I'm not sure if they go around the + or the &.

[jeroenbeijer]

I missed that part, I guess I did not look much further than my nose is long as we say in Dutch :-)

The machine I built it on is very much newer than the one I run C band off at moment so I suppose that is why my builds were using the cpu instructions rather than the inline code but its not very portable I suppose.