DSP Robotics Support

martinvicanek wrote:

Exo wrote:Maybe topic for another thread?

Yes, please

Exo wrote:Hi Martin, do you think it is possible to do this trick with this code?

Code: Select all

polyintin addr;
polyintin max;
streamin index;
streamout out;

int zero = 0;
int temp = 0;
stage2;
mov eax,addr[0];
cmp eax,0;
jz bypass;

  cvtps2dq xmm0,index;
  maxps xmm0,zero;
  minps xmm0,max;
  pslld xmm0,2;
  paddd xmm0,addr;
  movaps temp,xmm0;
  
  //Read
  mov eax,temp[0];
  fld [eax] ; fstp out[0]; 

  mov eax,temp[1];
  fld [eax] ; fstp out[1];
  
  mov eax,temp[2];
  fld [eax] ; fstp out[2];

  mov eax,temp[3];
  fld [eax] ; fstp out[3];
    
bypass:

This reads directly from the address of a mem, instead of from the mem input or an array. Where eax is the actually memory address and we read the actual value by doing [eax] . I know it can work easy with the mem input because it is copied into a standard code array.

polyintin addr;
polyintin max;
streamin index;
streamout out;

int zero = 0;
int temp = 0;
stage2;
mov eax,addr[0];
cmp eax,0;
jz bypass;

  cvtps2dq xmm0,index;
  maxps xmm0,zero;
  minps xmm0,max;
  pslld xmm0,2;
  paddd xmm0,addr;
  movaps temp,xmm0;
  
  //Read
  mov eax,temp[0];
  movaps xmm0,[eax];
  movaps out,xmm0;
     
bypass:

Exo wrote:Thanks to KG for writing the Opcode reference, I was just reading about "movaps xmm0,[eax];" and realized that was perfect for this case. Because it just reads in 128bits starting from the address in temp[0] essentially reading in 4 floats at once Of course it assumes data is aligned, if you are passing random index it won't work correctly. But for my case of saving phase per voice it is perfect.

KG_is_back wrote:

Exo wrote:Thanks to KG for writing the Opcode reference, I was just reading about "movaps xmm0,[eax];" and realized that was perfect for this case. Because it just reads in 128bits starting from the address in temp[0] essentially reading in 4 floats at once Of course it assumes data is aligned, if you are passing random index it won't work correctly. But for my case of saving phase per voice it is perfect.

Is it working? I'm not sure if mems are actually aligned to work like that.

Exo wrote:

KG_is_back wrote:

Exo wrote:Thanks to KG for writing the Opcode reference, I was just reading about "movaps xmm0,[eax];" and realized that was perfect for this case. Because it just reads in 128bits starting from the address in temp[0] essentially reading in 4 floats at once Of course it assumes data is aligned, if you are passing random index it won't work correctly. But for my case of saving phase per voice it is perfect.

Is it working? I'm not sure if mems are actually aligned to work like that.

Yep try this...

Free-running-poly-osc-V1.3ReadTest.fsm

It makes sense really, it is reading in 128 bits starting from the address in temp[0]. Arrays are always aligned, each element is one after the other. So 128bits on from the start address is covering the first 4 floats of the array.

Exo wrote:By the way I have been researching some more opcodes before I contact Malc, and what do you think to SSE3? There seems to be some really nice opcodes for complex math . Math isn't my strongest point but I think they might enable a nice fast FFT, So I am going to ask for them also if you think they are worthwhile?

KG_is_back wrote:

Exo wrote:By the way I have been researching some more opcodes before I contact Malc, and what do you think to SSE3? There seems to be some really nice opcodes for complex math . Math isn't my strongest point but I think they might enable a nice fast FFT, So I am going to ask for them also if you think they are worthwhile?

They seem really cool, but I'm afraid of compatibility issues. Basically all of them can be implemented by putting shufps or mulps before addps/subps. They sort of save CPU by decreasing the number of instructions needed to do complex math, but they are definitely not high on my list, since they wouldn't add new features.

KG_is_back wrote:Is it working? I'm not sure if mems are actually aligned to work like that.
EDIT:
Just did a test and it crashes when mem address is not divisible by 16. Fortunately there is a Fix - simply round up the pointer of the address to nearest multiple 16. Also make the mem to have +16 bytes to not run out of space at the end of the mem.

[(@addr+16)-(@addr%16)].pack('L').unpack('F')[0]