Saturating Arithmetic

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 ?

Thx in advans, Karthik Balaguru

Reply to
karthikbalaguru
Loading thread data ...

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.

Meindert

Reply to
Meindert Sprang

Not a lot of detail, but this may help:

formatting link

Reply to
Arlet

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
 Click to see the full signature
Reply to
Tim Wescott

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).

Joseph

Reply to
Joseph

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.

Reply to
steve

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.

Reply to
Jim Stewart

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.

--
Andrew Smallshaw
andrews@sdf.lonestar.org
Reply to
Andrew Smallshaw

Yes, all the time.

Obviously it isn't

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.

Reply to
steve

It's "standard" in controller algorithms. If the result of your controller overflows, often the best option is to output the maximum.

--
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)
Reply to
Stef

In my experience, code such as this quickly transforms into:

a = b - c;

Reply to
s0lstice

In my experience, code such as this quickly transforms into:

a = b - c;

if (a < 0) { a = 0; ... report the over/under-flow and maybe take some other measures ... }

Silently saturating is not usually the whole answer.

-- s0lstice

Reply to
s0lstice

Yes.

Karthik Balaguru

Reply to
karthikbalaguru

Nice way of explaining the saturation arithmetic :):)

Logical.

Clear explanation !!

Karthik Balaguru

Reply to
karthikbalaguru

Yes. That scenario can lead to some annoying bugs :):)

Karthik Balaguru

Reply to
karthikbalaguru

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.

--
Andrew Smallshaw
andrews@sdf.lonestar.org
Reply to
Andrew Smallshaw

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.

--
Andrew Smallshaw
andrews@sdf.lonestar.org
Reply to
Andrew Smallshaw

On some, if not most, embedded systems where, how, and to whom do you report the problem?

Reply to
Everett M. Greene

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.

Reply to
s0lstice

How does an embedded system treat "totally unacceptable"? Short of self-destructing, it has to do something.

John

Reply to
John Larkin

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.