On Thursday, November 17, 2022 at 2:20:08 PM UTC-6, Stephen Fuld wrote:
> On 11/17/2022 11:36 AM, MitchAlsup wrote:
> > On Thursday, November 17, 2022 at 9:36:22 AM UTC-6, timca...@aol.com wrote:
> >> On Thursday, November 17, 2022 at 1:25:42 AM UTC-5, Thomas Koenig wrote:
> >>> Seems like saturating arithmetic is a thing, apparently with
> >>> integers. I can see that for applications that interface with
> >>> the real world with limited-range sensors or actuators (no sense
> >>> in trying to put more than 20 mA on a 4-20 mA current loop).
> >>>
> >>> And floating point (usually?) does not need it.
> >>>
> >>> What's the best way of encoding this in an ISA? To cover the
> >>> range of 8,16,32,64 bit calculations would need two bits. Or,
> >>> if somebody has, let's say, a 12-bit sensor, intermediate lengths
> >>> might also come in handy to clip results to between -2048..2047.
> >>>
> >>> Or is it just not worth the bother? Maybe people who have
> >>> experience with embedded CPUs can say something about this.
> > <
> >> IIRC, saturating adds & subtracts are used for things like JPEG & MPEG encoding/decoding.
> >> For 12 bit, you could do 16 bit and then have ceiling/floor operations to "clip" the result.
> > <
> > For ADA: one would want to saturate at particular end-of-range which
> > may not be power of 2.
> > Do most of the rest: one would saturate to the size of a container which
> > may not be a power of 2.
> > <
> > If one can avoid integer overflow in the actual calculation, one can
> > have an extract instruction (or a saturate instruction) that provides
> > the necessary bounds (operands) and an instruction that does::
> > <
> > if( x < lbounds ) r = lbounds;
> > else if( x > ubounds ) r = ubounds;
> > else r = x;
> A few comments.
>
> 1. I think that saturating arithmetic is a pretty big thing in DSPs. If
> that is so, then perhaps someone who is familiar with the usage patterns
> there can chime in.
>
> 2. I recall that the Mill will offer saturating arithmetic. Perhaps
> Ivan can provide more information.
>
> 3. There is a fundamental question of whether to include the saturation
> in the arithmetic instructions or as a separate instruction after the
> arithmetic instruction. There are arguments on both sides.
>
>
> 4. Your example requires a three operand instruction. This is
> frequently overkill, as for example, if the arithmetic operation was an
> unsigned add, there is no need to test the lower bounds, and a simple,
> two operand MAX instruction would be sufficient.
>
>
>
> --
> - Stephen Fuld
> (e-mail address disguised to prevent spam)

A three operand median instruction does saturation between arbitrary bounds, for speed it needs three comparators.
Used in image processing and DSP for spike removal, have not seen median in any ISA?
Of course a MAX MIN pair will do the job for saturation.

On Sunday, May 14, 2023 at 7:32:09 PM UTC+1, JimBrakefield wrote:

> Of course a MAX MIN pair will do the job for saturation.

only if you are prepared to sacrifice 2x more of the regfile
(assuming Vector-Packing or PackedSIMD), unless you
have a Carry-Out and/or Overflow Condition-Code flag

assuming that you are not doing huge horizontal-sum
arithmetic the rollover (or borrow) will only be in the N+1th bit.

but if you do not have CCs/Carry then the only way to
know *after the fact* is to use 2N-wide arithmetic ops,
then use 2N-wide MAX and 2N-wide MIN to limit to an
N-wide result that *only then* can be safely Vector-Packed
or Packed-SIMD at width N

and given that you can only do 1/2 the number of operations
you now have far larger register spill and/or far larger
regfiles than otherwise necessary, at which point your Audio/Video
DSP product is no longer commercially competitive in either
die area or power consumption.

if the MIN/MAX is driven by N+1 by taking an extra carry-in
bit *then* you can stay at N-wide rather than 2N-wide.
can anyone forsee any problems with that?

MIN(RA, RB, CA): if RA+(CA<<N) < RB return RA else RB

On Monday, May 15, 2023 at 9:08:51 PM UTC-5, luke.l...@gmail.com wrote:
> On Sunday, May 14, 2023 at 7:32:09 PM UTC+1, JimBrakefield wrote:
>
> > Of course a MAX MIN pair will do the job for saturation.
> only if you are prepared to sacrifice 2x more of the regfile
> (assuming Vector-Packing or PackedSIMD), unless you
> have a Carry-Out and/or Overflow Condition-Code flag
>
> assuming that you are not doing huge horizontal-sum
> arithmetic the rollover (or borrow) will only be in the N+1th bit.
>
> but if you do not have CCs/Carry then the only way to
<
Only is too strong, change that to obvious.
<
> know *after the fact* is to use 2N-wide arithmetic ops,
> then use 2N-wide MAX and 2N-wide MIN to limit to an
> N-wide result that *only then* can be safely Vector-Packed
> or Packed-SIMD at width N
<
You also have the problem of type consistency::
Is ADD Rd,Rs,#0xFFFFFFFF
A subtract by 1 or an add of a huge number ???
And how do you tell the difference.
>
> and given that you can only do 1/2 the number of operations
> you now have far larger register spill and/or far larger
> regfiles than otherwise necessary, at which point your Audio/Video
> DSP product is no longer commercially competitive in either
> die area or power consumption.
>
> if the MIN/MAX is driven by N+1 by taking an extra carry-in
> bit *then* you can stay at N-wide rather than 2N-wide.
> can anyone forsee any problems with that?
>
> MIN(RA, RB, CA): if RA+(CA<<N) < RB return RA else RB
<
Don't see how that works::
<
MIN(MAX(calculated, biglimit), littlelimit)

On Tuesday, May 16, 2023 at 9:29:54 AM UTC-5, MitchAlsup wrote:
> On Monday, May 15, 2023 at 9:08:51 PM UTC-5, luke.l...@gmail.com wrote:
> > On Sunday, May 14, 2023 at 7:32:09 PM UTC+1, JimBrakefield wrote:
> >
> > > Of course a MAX MIN pair will do the job for saturation.
> > only if you are prepared to sacrifice 2x more of the regfile
> > (assuming Vector-Packing or PackedSIMD), unless you
> > have a Carry-Out and/or Overflow Condition-Code flag
> >
> > assuming that you are not doing huge horizontal-sum
> > arithmetic the rollover (or borrow) will only be in the N+1th bit.
> >
> > but if you do not have CCs/Carry then the only way to
> <
> Only is too strong, change that to obvious.
> <
> > know *after the fact* is to use 2N-wide arithmetic ops,
> > then use 2N-wide MAX and 2N-wide MIN to limit to an
> > N-wide result that *only then* can be safely Vector-Packed
> > or Packed-SIMD at width N
> <
> You also have the problem of type consistency::
> Is ADD Rd,Rs,#0xFFFFFFFF
> A subtract by 1 or an add of a huge number ???
> And how do you tell the difference.
> >
> > and given that you can only do 1/2 the number of operations
> > you now have far larger register spill and/or far larger
> > regfiles than otherwise necessary, at which point your Audio/Video
> > DSP product is no longer commercially competitive in either
> > die area or power consumption.
> >
> > if the MIN/MAX is driven by N+1 by taking an extra carry-in
> > bit *then* you can stay at N-wide rather than 2N-wide.
> > can anyone forsee any problems with that?
> >
> > MIN(RA, RB, CA): if RA+(CA<<N) < RB return RA else RB
> <
> Don't see how that works::
> <
> MIN(MAX(calculated, biglimit), littlelimit)

Yes there is a problem. For signal processing where data is typically 12-bits, not so much.