Re: RFC: Generic Fixed-Point IIR Filter

[Patrick Noffke <patrick.noffke@gmail.com>]

On Thursday, March 26, 2015 at 12:41:29 PM UTC-5, Jeffrey Carter wrote:
> On 03/26/2015 09:25 AM, Patrick Noffke wrote:
> 
> All generic formal parameters are non-static. As to a non-static type consider
> 
> generic -- P
>    type T is range <>;
> package P is ...
> 
> and then
> 
> function Input return Natural;
> -- Obtains a value of subtype Natural from the user
> 
> ...
> 
> subtype U is Integer range 1 .. Input;
> 
> package Q is new P (T => U);
> 
> Clearly subtype U is non-static, and so formal type T is also non-static.
> 

I didn't know you could do this.  Thanks.

> > 
> >  - If I try to use Fixed_Type for X_Array and Y_Array, then I do in fact get a constraint error (due to range overflow for an intermediate calculation).  Is there a better way to do a calculation for a fixed-point type when you expect the result to be within the specified range of Fixed_Type, but intermediate calculations may not?
> 
> All your problems result from suffixing type names with _Type :)
> 
I should have known! :-)

> I refer you to ARM 4.5.5, specifically ¶18-19. Multiplication and division
> between fixed-point values gives results of type universal_fixed, which is
> implicitly convertible to any fixed-point type. When you write
> 
> Filter.Y_Array (1) := Filter.B (1) * X;
> 
> you are multiplying a Filter_Value_Type * Fixed_Type yielding universal_fixed,

How is universal_fixed (likely) implemented on a 32-bit processor?  What happens if you multiply two fixed-point types that use all 32-bits for range and precision?  What if one type uses all the bits for the range and another uses all the bits for precision?

I'm targeting an ARM Cortex-M4 processor, but writing test code on an x86_64 PC.  In my test code with FSF GNAT, I noticed from a hex print of a Pressure_Type variable that only the minimum number of bits were used (as I understand it, with Ada 95 and later, small *could* be smaller than the maximum allowable small).

I know the M4 processor has the SMULL instruction (Signed Multiply (32x32), 64-bit result) and similar instructions, but I don't yet know if the compiler is using these for universal_fixed.

> which is then implicitly converted to the type of the LHS, Filter_Value_Type.
> Your exceptions result from attempting to convert intermediate results to
> Fixed_Type, which lacks the range needed to hold the values. It is therefore
> sometimes possible to avoid the 2nd type if all calculations can be done in a
> single expression which yields a value that fits in the smaller type, despite
> having intermediate results which do not. That doesn't seem to be case for your
> problem, though.
> 

True, for the generic package.  But I really only need a 2nd order filter for my application, so I should be able to do:

Filter.Y_Array (1) := (Filter.B (1) * X (1) + Filter.B (2) * X (2) + Filter.B (3) * X (3) - Filter.A (2) * Filter.Y_Array (2) - Filter.A (3) * Filter.Y_Array (3)) / Filter.A (1);

Then every product is universal_fixed, so the sum is universal_fixed, and implicitly converted to the LHS type.  But again, I'd like to know what is happening under the hood to implement this.

> Some comments on your implementation:
> 

Thank you for those.  I will address the issues you point out.

Patrick