Bitwise strangeness

[Nowhk]

At the moment, I really don't understand these 2 things in FlowStone DSP Code (let isLoop = 1).

First uncertainty

Code: 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 uncertainty

Code: 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!

[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

[Nowhk]

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...

[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

[Nowhk]

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!

[stw]

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

Code: Select all

40 & ((22) % 40)

which explains the result of 2.5

I'm on 3.04

[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;

[Nowhk]

But that's only rarely used as it is quite CPU heavy anyway.

This means that I should avoid modulo % on DSP code?

[MyCo]

You can still use it, but not in complex statements

[Nowhk]

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?).