Hi, I find that ARM has Support for Saturating Arithmetic. I searched the internet , but i did not find enough informationi regarding Saturating Arithmetic ?
Can someone here provide me with a link that talks in detail about this Saturating Arithmetic ?
It means that in case of an overflow after a calculation, the result saturates to the maximum or minimum value that can be held by the destination register. The register will never roll over from for instance a high positive value to a negative value and vice versa.
Most fixed-point DSP chips (I dunno about floating-point ones) have an accumulator that's significantly wider than the data -- e.g. the ADI 21xx family has a 40-bit accumulator for use with 16-bit data, the TI '28xx family has an 'overflow counter' that acts as another 7 or 8 bits worth of accumulator. These are used to do saturation _after_ a vector dot product, so even if intermediate values would overflow, the saturation only happens if the result would overflow.
Do you know if the ARM does that? It's certainly handy for DSP work.
--
Tim Wescott
Control systems and communications consulting
Yes, if you are using ARMv5TE (e.g. ARM926EJ-S) or above, you already got QADD, QDADD, QSUB and QDSUB instructions for add/subtract with saturation.
For Cortex-M3, it has SSAT and USAT for signed and unsigned saturation instruction to convert 32-bit values into smaller sizes with saturation. There are also 32bit multiply instructions and 32-bit multiply-accumulate instructions (results are 64-bits).
More DSP instructions are available in ARM11 (v6 architecture) and Cortex-A8 / R4 processors (v7 architecture).
Are there certain areas where the use of saturation arithmetic is deemed acceptable and "standard"? In my area of embedded work, any computation that results in a overflow would be considered a complete failure of the software design and totally unacceptable.
Audio and servo systems come to mind first. Saturation causes clipping, which is far better than a rail-to-rail signal flip. Existing data might properly drive a computation into the rail and having saturation arithmetic might eliminate a time consuming test for such a condition.
It depends on the application and the particular circumstances. Can you honestly say you have never written code such as
a = b - c;
if (a < 0) a = 0;
or some other way of stating the same thing? Obviously it isn't appropriate all of the time but sometimes it is exactly what is needed. I've used code like this extensively in image processing jobs where it is fine for a colour to become black slightly earlier than anticipated because of the vagaries of the input, but you don't want that result to wrap around to some bright colour. Saturating arithmetic avoids the need for the if portion since its operation is implied in the subtraction.
The textbook example of this is probably in audio where if two signals are combined to yield a result greater than the maximum possible, or a single signal amplified beyond that point, the sensible course of action is to output that maximum. Sure, that means clipping the signal but often a small amount of clipping doesn't have too adverse an effect on sound quality. What you don't want is for the signal to wrap around to a value at the wrong end of the range which would sound awful.
And as for completely avoiding overflow in calculations, again, it depends on the situation. I have in the past written code that I knew full well could overflow in certain conditions. It wasn't a problem because later on another calculation would inevitably underflow in those circumstances and the result would be correct. This doesn't happen very often but it's useful to bear in mind at times. Of course, defensive programming requires you to comment those sections of code so that is apparent what the hell is going on - you don't want somebody half "fixing" your code and breaking it in the process.
Ok, so it's a speed issue. I guess if it only used in certain areas of the software and properly documented I can see it's advantage. I was incorrectly thinking that when it was used it was used all the time everywhere.
Yea, that's a big disadvantage, but if you need the speed ...well I've broken a lot of rules when I start running out of memory or speed.
Well, I did say that this was dependent on the context. Of course, sometimes more needs to be done, but particularly in this instance (crossing zero), silently saturating _is_ the whole answer as many real life quantities are fundamentally unsigned to begin with. Whilst mathematically
small - big = negative
in the context of modelling many real-life quantities it really is the case that
small - big = zero
For instance, to return to my image-processing example. What happens to black when we attempt to darken it? Nothing. It is already black and there simply isn't any concept of something darker.
Other times, real world factors have an effect even if conceptually a negative value would be a possibility. Consider a crane holding an object 100 ft above the ground. If the crane winds out 10 ft of cable then the object sinks to 90 ft above the ground. If the same crane winds out 200 ft of cable then the object does not sink to 100ft below ground level even though that makes conceptual sense. Instead the ground limits things and the object rests on the ground (ie zero height) instead of passing through it. Yes, this may be a specific example but there are many such examples, and embedded systems are if anything more likely to encounter them because in general they interface to the real world in some manner.
Also, in the general case the code above (or indeed my original code) doesn't work for detecting overflow unless we widen the data we are working on - unsigned variables _can't_ be negative for instance. Instead I wrote my original version to illustrate circumstances where saturating arithmetic (as opposed to conventional overflow) can be useful since the snippet represents a reasonably common structure in my code at least.
Well, I did say that this was dependent on the context. Of course, sometimes more needs to be done, but particularly in this instance (crossing zero), silently saturating often _is_ the whole answer as many real life quantities are fundamentally unsigned to begin with. Whilst mathematically
small - big = negative
in the context of modelling many real-life quantities it really is the case that
small - big = zero
For instance, to return to my image-processing example. What happens to black when we attempt to darken it? Nothing. It is already black and there simply isn't any concept of something darker.
Other times, real world factors have an effect even if conceptually a negative value would be a possibility. Consider a crane holding an object 100 ft above the ground. If the crane winds out 10 ft of cable then the object sinks to 90 ft above the ground. If the same crane winds out 200 ft of cable then the object does not sink to 100ft below ground level even though that makes conceptual sense. Instead the ground limits things and the object rests on the ground (ie zero height) instead of passing through it. Yes, this may be a specific example but there are many such examples, and embedded systems are if anything more likely to encounter them because in general they interface to the real world in some manner.
Also, in the general case the code above (or indeed my original code) doesn't work for detecting overflow unless we widen the data we are working on - unsigned variables _can't_ be negative for instance. Instead I wrote my original version to illustrate circumstances where saturating arithmetic (as opposed to conventional overflow) can be useful since the snippet represents a reasonably common structure in my code at least.
Host system via attached comms, event log in RAM/file to be examined later, warning sound on piezo buzzer, flash code on error LED, or simply going into a 'safe' state if there is a safety issue.
I'm sure we could all point to embedded systems with none of these methods available, but I think they are the exception. I simply meant that just because it's possible on some processors to use assembler instructions that implement saturating arithmetic, that doesn't mean you can always avoid a further test to see if saturation has occurred.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.