If you have a problem or need to report a bug please email : support@dsprobotics.com
There are 3 sections to this support area:
DOWNLOADS: access to product manuals, support files and drivers
HELP & INFORMATION: tutorials and example files for learning or finding pre-made modules for your projects
USER FORUMS: meet with other users and exchange ideas, you can also get help and assistance here
NEW REGISTRATIONS - please contact us if you wish to register on the forum
Users are reminded of the forum rules they sign up to which prohibits any activity that violates any laws including posting material covered by copyright
DSP Round Up & Round Down
3 posts
• Page 1 of 1
DSP Round Up & Round Down
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
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
-
aronb - Posts: 154
- Joined: Sun Apr 17, 2011 3:08 am
- Location: Florida, USA
Re: DSP Round Up & Round Down
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...
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.
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.
All schematics/modules I post are free for all to use - but a credit is always polite!
Don't stagnate, mutate to create!
Don't stagnate, mutate to create!
-
trogluddite - Posts: 1730
- Joined: Fri Oct 22, 2010 12:46 am
- Location: Yorkshire, UK
Re: DSP Round Up & Round Down
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".
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".
We have to train ourselves so that we can improvise on anything... a bird, a sock, a fuming beaker! This, too, can be music. Anything can be music. -Biff Debris
-
Duckett - Posts: 132
- Joined: Mon Dec 14, 2015 12:39 am
3 posts
• Page 1 of 1
Who is online
Users browsing this forum: Mirek Suk and 18 guests