Page 1 of 3
Bitwise strangeness
Posted: Wed Feb 17, 2016 12:23 pm
by Nowhk
At the moment, I really don't understand these 2 things in FlowStone DSP Code (let
isLoop = 1).
First uncertaintyCode: Select all
(isLoop > 0) & 5 => 5 // its odd; it should just be 1
(isLoop > 0) & 5 => 6 // its even; it should just be 0
in fact:
0001 (isLoop > 0)
AND 0101 (5) is 0001 (1)
0001 (isLoop > 0)
AND 0110 (6) is 0000 (0)
Second uncertaintyCode: Select all
(isLoop > 0) & ((22) % 40) => 2.5
(isLoop > 0) & (22) % 40 => 22
The code looks "the same" (the second one it is just without the brackets), but it outputs very different.
In fact this:
Code: Select all
output = (isLoop > 0) & (60 + 1) + (isLoop == 0) & ((50 + 1) % 1000)
output 1000 instead of 51
And if I change isLoop to 0, it output 1051
Can you help me to got this? Thanks!
Re: Bitwise strangeness
Posted: Wed Feb 17, 2016 1:49 pm
by MyCo
Comparisons return bitmasks, so in 8bit(for simplicity) this is:
Code: Select all
(1 > 0) => true: 0b11111111
(1 < 0) => false: 0b00000000
This should give you an idea
Re: Bitwise strangeness
Posted: Wed Feb 17, 2016 1:58 pm
by Nowhk
MyCo wrote:Comparisons return bitmasks, so in 8bit(for simplicity) this is:
Code: Select all
(1 > 0) => true: 0b11111111
(1 < 0) => false: 0b00000000
This should give you an idea
Oh I see. Thanks!
And what about the second point? It seems that sum values after the comparison introduce the issues. If I remove "+1" (so 51 instead of 50+1) it works as expected.
But I don't see the point...
Re: Bitwise strangeness
Posted: Wed Feb 17, 2016 2:09 pm
by MyCo
The second thing is a limitation (and partially a bug) of FS < 3.0.9b1, the code line just uses to many registers. Try it in the beta version there it outputs 61 (which is correct):
Code: Select all
output = (isLoop > 0) & (60 + 1) + (isLoop == 0) & ((50 + 1) % 1000)
output = (1> 0) & (60 + 1) + (1== 0) & ((50 + 1) % 1000)
output = (1> 0) & (61) + (1== 0) & ((51) % 1000)
output = (1> 0) & (61) + (1== 0) & (51)
output = (1> 0) & 61 + (1== 0) & 51
output = (0b1111...) & 61 + (0b0000...) & 51
output = 61 + 0
output = 61
Re: Bitwise strangeness
Posted: Wed Feb 17, 2016 2:16 pm
by Nowhk
MyCo wrote:The second thing is a limitation (and partially a bug) of FS < 3.0.9b1, the code line just uses to many registers. Try it in the beta version there it outputs 61 (which is correct):
Code: Select all
output = (isLoop > 0) & (60 + 1) + (isLoop == 0) & ((50 + 1) % 1000)
output = (1> 0) & (60 + 1) + (1== 0) & ((50 + 1) % 1000)
output = (1> 0) & (61) + (1== 0) & ((51) % 1000)
output = (1> 0) & (61) + (1== 0) & (51)
output = (1> 0) & 61 + (1== 0) & 51
output = (0b1111...) & 61 + (0b0000...) & 51
output = 61 + 0
output = 61
I see. I'll try when I buy it (I'll wait the official release to get complete with it, after Beta).
Thanks man!
Re: Bitwise strangeness
Posted: Wed Feb 17, 2016 10:37 pm
by stw
MyCo wrote:The second thing is a limitation (and partially a bug) of FS < 3.0.9b1, the code line just uses to many registers. Try it in the beta version there it outputs 61 (which is correct):
Seems to be a bit more than that. Watch the asm code this line produces:
Code: Select all
streamout out;
out = (1 > 0) & ((22) % 40);
==>
Code: Select all
movaps xmm0,F1;
cmpps xmm0,F0,6;
movaps xmm0,F22;
movaps smIntVarTemp,xmm0;
movaps xmm0,F40;
...
movaps smIntVarTemp2,xmm0;
movaps xmm1,smIntVarTemp;
...
andps xmm0,xmm1;
movaps out,xmm0;
Obviously FS falsely overwrites xmm0 which yields to
which explains the result of 2.5
I'm on 3.04
Re: Bitwise strangeness
Posted: Wed Feb 17, 2016 10:49 pm
by MyCo
Yeah, weird that this was only found now... This bug was there for years, and is basically caused by a bug in the Asm code for the modulo operator. But that's only rarely used as it is quite CPU heavy anyway.
When I built the new compiler in 3.0.9b1 I found some bugs in the old compiler too (it produced very inefficient asm when using a lot of operands). The new compiler is a lot more efficient and uses SSE2.
Code: Select all
streamout out;
float _F_1=1, _F_0=0, _F_22=22, _F_40=40;
// Comparison
movaps xmm0,_F_1;
cmpps xmm0,_F_0,6;
// Modulo
movaps xmm2,_F_22;
movaps xmm1,xmm2;
divps xmm2,_F_40;
cvttps2dq xmm2,xmm2;
cvtdq2ps xmm2,xmm2;
mulps xmm2,_F_40;
subps xmm1,xmm2;
// '&' Operator
andps xmm0,xmm1;
// Assign to 'out'
movaps out,xmm0;
Re: Bitwise strangeness
Posted: Thu Feb 18, 2016 9:22 am
by Nowhk
MyCo wrote:But that's only rarely used as it is quite CPU heavy anyway.
This means that I should avoid
modulo % on DSP code?
Re: Bitwise strangeness
Posted: Thu Feb 18, 2016 11:14 am
by MyCo
You can still use it, but not in complex statements
Re: Bitwise strangeness
Posted: Thu Feb 18, 2016 11:27 am
by Nowhk
MyCo wrote:You can still use it, but not in complex statements
I meant: is it an heavy operation for DSP code that should be not used? (due to its intensive CPU usage?).