Mem address crash discussion (split from DSP code 2)

[MyCo]

Also the mem is 32bit aligned, even 64bit aligned (at least on my machine, DUNNO if it's machine specific), but to use SSE operations 128bit alignment is necessary.

On my machines it's always 128Bit aligned

[Exo]

There are cases or at least there was where the mem to address outputs -1. As MyCo has pointed out the problem is that most(maybe all?) mem components (float array to mem, wave file ect) have an address, even if the data is not valid. This means we have no way of knowing whether to read from the address or not.

I only have one crashing case at the moment that is or should I say was a problem.

For fast loading times I create wavetables in a new thread on load. This means that the audio section loads before the wavetables have been fully created. If you play notes before the wavetables have been created (within the first 2-3 seconds) then the address is invalid and we get a crash.

I have fixed this by using an after load trigger to set the address to zero then create the wavetable. So now if I play notes within the first few seconds after loading I get silence while the table is created.

I'm sure it would be possible to set the mem address to zero for other cases too.

[Tronic]

Also the mem is 32bit aligned, even 64bit aligned (at least on my machine, DUNNO if it's machine specific), but to use SSE operations 128bit alignment is necessary.

On my machines it's always 128Bit aligned

in my machine the test result in not always true

[Exo]

Flowstone 3.0.8 has been released which has an update to the mem to address

Fixed a problem with the Mem Address component so it now gives a zero value for address and size if there is no valid Mem connected

[MyCo]

Nice! This wasn't fixed in the betas Malc sent (when I remember correctly), so he might have fixed it in the last minutes. Fingers crossed, nothing was broken in the process

[KG_is_back]

I'm thinking of a one thing. is it possible to create a "dummy" address?
Let's say I have a different address in every channel (sort of like wave array read - the address is picked from a table).
that way we instead of using this code for reading from mem:

Code: Select all

streamin addr;
streamin index; //assuming is already in int format
streamout out;

mov eax,addr[0];
cmp eax,0;
jz invalidAddress0;
add eax,index[0]; mov eax,[eax];  mov out[0],eax;
invalidAddress0:

mov eax,addr[1];
cmp eax,0;
jz invalidAddress1;
add eax,index[1]; mov eax,[eax]; mov out[1],eax;
invalidAddress1:
...

basically checking every address and using conditional jumps to prevent reading, we can switch between the address and "dummy address" if it's invalid:

Code: Select all

streamin addr; streamin index; streamout out;
int TempAddr=0;
int DummyAddress=???; // <- I'm asking how to get this
movaps xmm0,addr;
movaps xmm1,xmm0;
cmpps xmm1,I0,0; //if equal to zero
andps xmm1,DummyAddress;
orps xmm0,xmm1; //remember, invalid address is already zero
movaps tempAddr,xmm0;

//now no jumps are needed because tempAddr contains only valid addresses
mov eax,tempAddr[0]; mov eax,[eax]; mov out[0],eax;
mov eax,tempAddr[1]; mov eax,[eax]; mov out[1],eax;
mov eax,tempAddr[2]; mov eax,[eax]; mov out[2],eax;
mov eax,tempAddr[3]; mov eax,[eax]; mov out[3],eax;

andnps xmm1,out; //make values from dummyAddress zero (this is optional if it already contains zero)
movaps out,xmm1;

I've tried to use ebp (base pointer) to create address that is surely valid, but unfortunately it doesn't work.
I tried next 16byte aligned address after ebp, but it still crashes (I wonder why, because clearly it is part of the stack).

[MyCo]

Depends on how big your dummy memory has to be. You could use for example the existing sine table as dummy. Its address is stored in the predefined variable "sine" and has a size of 64k floats.

[KG_is_back]

thanks MyCo, totally forgot about that one...
I wonder which solution would be faster. Using conditional jumps to skip parts of code may cause code pre-fetching to fail, thus increasing CPU. On the other side, reading from un-pre-fetched memory block (a one that is not in cache) may have similar consequences.
I will test them both tomorrow and led you guys know...