Re: Hard real-time systems

Re: Hard real-time systems

[Mats Weber]

Robert I. Eachus wrote:

>     Now to the, for Ada, tougher question.  Saturating types can be
> supported easily for integer and floating types, but for fixed point
> [...]

What is a saturating type ?

Re: Saturated Arithmetic

[Markus Kuhn]

Mats Weber wrote:
> What is a saturating type ?

Saturated/saturating arithmetic is a variant of integer or
fixed-point arithmetic in which

  T'Last + 1 = T'Last
  T'First - 1 = T'First

etc., i.e. where overflows and underflows of computations
result in the closest representable value, and not in a
wraparound or exception.

Such types are *very* widely used in digital signal processing.
If your result in an audio filter algorithm happens to be
slightly above 16#ffff#, then the output you want is 16#ffff# as
the closest possible approximation to the real result and you
clearly do not want a wraparound to 16#0000# or an exception or
extra code that has to take care of this in inner loops.

Most DSPs as well as the new Intel MMX instructions provide
hardware support for saturated arithmetic. I guess, adding
saturated integer and fixed point types to Ada0X would be a sensible
idea (at least if there will be a digital signal processing
special annex).

Markus

-- 
Markus G. Kuhn, Security Group, Computer Lab, Cambridge University, UK
email: mkuhn at acm.org,  home page: <http://www.cl.cam.ac.uk/~mgk25/>

Re: Hard real-time systems

[Robert I. Eachus]

In article <6m6vkp$8un@gurney.reilly.home> reilly@zeta.org.au (Andrew Reilly) writes:

 > A question for the Ada camp: does Ada let you deal with the
 > notion of an accumulator that is wider than the source operands?
 > For example, the natural DSP operation a = a + x1 * y1 on the
 > 56k has x1 and y1 of the type described above, but a is a 56-bit
 > variable in the range [-256,256-2^{-47}].  Also, the natural
 > conversion from a to 24-bit quantity produces saturation on
 > overflow.  Are there any high-level languages with types that
 > can do that?  Maybe that's not a language issue.

   Ada naturally supports the first class of operations.  For fixed
point types, the language defined fixed * fixed --> fixed and fixed /
fixed --> fixed operations return an unbounded type which must be
converted to some (bounded) numeric type.  So if you write:
 
procedure fixed56 is
 
    type Fixed_56 is delta 2.0**(-47) range -256.0..256.0;
    type Fixed_24 is delta 2.0**(-23) range -1.0..1.0;
    type Vector is array(Integer range <>) of Fixed_24;

    A: Fixed_56 := 0.0;
    X, Y: Vector(1..100) := (others => 0.5);

   begin 

    for I in X'Range loop
      A := A + X(I) * Y(I);
    end loop;
    
end fixed56;

    On a compiler targeted to that chip, you should get the very
efficient code you expect.  BUT, and this is the nice thing about Ada,
I just compiled that on a Sun to check that the code was correct.  It
won't be very efficient on some older Suns, but it will still give the
same answers.

    Now to the, for Ada, tougher question.  Saturating types can be
supported easily for integer and floating types, but for fixed point
types, you need compiler support for non-standard fixed-point types,
or you have to use non-standard syntax for some of the saturating
operations.  The saturating conversion would best be provided as a
compiler defined operation.
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...