DSP Robotics Support

Happy New Year to ALL ! ! !

I am testing a few things regarding the DSP and ASM versions of code to perform the Int() or "Round Down" and RndInt() or "Round Up" functions, and would like to both share and have some feedback on if these modules are behaving properly please(?)



I do not normally write ASM code, and so any feedback on my code would be useful as well!

Thank you, Aron

The "round down" modules look about right to me. For a 32-bit float, the best adjustment value is 0.49999997 - that's the next closest value to 0.5 that you can get (NB: I'm not sure that this technique is totally infallible, but it's what usually gets used).

The "round up" modules look wrong to me - they are "round nearest" (more correctly "bankers rounding" as determined by the CPU). I would expect even e.g. 0.00001 to round-up to 1.0 (the "ceil()" function in many languages).

What I can say for sure is that there is a cool ASM trick which is useful here. Using the "frndint" operand is quite slow, partly because you need the "Temp" variable. Also, the code that you have works only for the first SSE channel - to use it for poly or mono4 streams, you'd have to repeat the code for Temp[1], Temp[2], and Temp[3].

A much faster way is this...

Code: Select all

// Assume xmm0 contains the value for rounding...
cvtps2dq xmm0, xmm0; // Convert SSE to integer representation.
cvtdq2ps xmm0, xmm0; // Convert SSE back to float representation.
// xmm0 has the rounded value.

This works because the CPU has to round the value in order to convert to integer representation, and then it is the rounded version that gets converted back to floating point. Better still, it does all four SSE channels in one go, and very quickly. In every other sense, it does just the same as "frndint", so if you need adjustments for rounding up or down (e.g. the 0.4999999), you'd do them in the same way.

Hey, so- I'm here because (whether or not this is something I should need to do,) I was looking for a simple way to round nearest for float or mono (for the sake of tidy ms values), and what's in the toolbox is apparently poly (which won't convert with the usual kludges)... it looks like this li'l chunk o' code might be exactly what the doctor ordered.

Is there anything else you think I should be bearing in mind, when on similar forays into the wild and woolly realm of data type conversion within FS, other than the usual "don't try too hard to fool FS into accepting one type as another when and where it doesn't belong, unless you like crashing a lot"? It always seems like, even though I generally comprehend OOP faster initially, when it comes down to wanting to just get something done as simply and CPU-efficiently as possible, "There's code for that".