Saturation arithmetic

For x86, when an integer overflows the processor sets the carry bit. The adc and sbb instructions add/subtract a number plus the carry bit. Also, the cmovc instruction can move data conditionally using the carry bit. So for an addition of a positive integer you can use:

add eax, ebxmov ecx, 0x7FFFFFFFcmovc eax, ecx

It's more complicated for signed additions but I hope I've set the tone.

By the way, why don't you use floating-point numbers? Then you can easily let the values grow beyond range and then clamp them in the end. It's a more correct approach I believe. And with SSE assembly it might even be faster in whole.

Quote:

Original post by C0D1F1ED By the way, why don't you use floating-point numbers? Then you can easily let the values grow beyond range and then clamp them in the end. It's a more correct approach I believe. And with SSE assembly it might even be faster in whole.

You would have to use doubles to get the desired precision (floats are too small with only 24 bits of mantissa). Which means SSE2 only and 2 calculations per SSE2-op instead of 4 with 32-bit ints.

Quote:

Original post by Trap You would have to use doubles to get the desired precision (floats are too small with only 24 bits of mantissa). Which means SSE2 only and 2 calculations per SSE2-op instead of 4 with 32-bit ints.

I can't imagine 32-bit floats wouldn't be sufficient for an audio sequencer.

Quote:

Original post by C0D1F1ED Quote: Original post by Trap You would have to use doubles to get the desired precision (floats are too small with only 24 bits of mantissa). I can't imagine 32-bit floats wouldn't be sufficient for an audio sequencer.

There is no use for the 8 bit exponent in audio processing (except for things like clamping). That leaves you with the 24-bits of the mantissa. The audio data you are processing is 24-bit with maybe 20 or 21 bit of real data and 4 or 3 bits of noise.

Implementing things like dynamic compressors, equalizers, IIR-filters and so on with only 3 bits of errormargin till your errors start degrading the signal is a bad idea IMO.

Quote:

Original post by Trap There is no use for the 8 bit exponent in audio processing (except for things like clamping). That leaves you with the 24-bits of the mantissa. The audio data you are processing is 24-bit with maybe 20 or 21 bit of real data and 4 or 3 bits of noise.

The exponent is used as well! If the dynamic range is halved you don't loose any precision, it just lowers the exponent. This also means you get high precision for faint sound, instead of bigger granularity like with integers. You simply always have 24 bits or precision no matter what the range is.

In other words when your sound is scaled between -1.0 and 1.0 you're using 31 bits of the whole 32-bit floating-point format!

In the x86 there is an overflow condition code. If it is true, then set the result to 0x7fffffff or 0x80000000 depending on the sign of one of the operands and the operation.