Agner`s CPU blog

for(int i=0; i<nb_samples_to_do;)
{
int block_samples = nb_samples_to_do - i;
if(block_samples > 64) { block_samples = 64; }
[process block_samples items];
i += block_samples;
}

I think the scaled indexed addressing mode is mainly there for another reason: reading look-up tables, and other cases where the array index is calculated on the fly inside the loop (2D texture mapping, audio resampling and so forth). This addressing mode mostly makes sense for scalar integer and floating-point operations though (and scatter/gather operations if you end up having those).

For SIMD code, you tend to have free leftover cycles on the integer scalar part of the cpu so I don't feel that addressing modes are all that important - on the ARM NEON code that I did, I could simply do pointer updates and recalculations for the addressing types that the NEON didn't allow because performance was limited by the NEON unit anyways. On the other hand, you can also allow fancier addressing modes like post-increments in SIMD code because they don't use the same register files (MIPS has this: integer loads/stores are register+offset ONLY, but floating point loads/stores also allow register+register*4 since it doesn't create the case where store operations need 3 input registers; ARM NEON has a post-increment addressing mode where the increment is the SIMD load width).

Come to think of it, would it make sense to adapt the code for different maximum SIMD vector length in the relocation pass? (ie when correcting all jump offsets when loading a DLL or doing address layout randomization to prevent hacking when loading executables)