Hi Steve,
Yes I like the ideas you suggested, and have been thinking along similar
lines. I have done a few fixed point projects, and now feel it's a step
of engineering steps for me, rather than guesswork (which was how I
started). So parts of it (at least) could be automated.
Jean-Marc Valin has some macros in Speex that go part of the way (e.g.
they implement fixed point operations, handle saturation and Q formats).
I use algebra in comments that describes the float-fixed transformation
and regular C code. Both of these approaches go part of the way.
My idea system would work like this. You have some floating point code
that you annotate, then pass it through a float-fixed compiler/parser.
The code might look like:
{
FIXED a,b; /* fixed: Q3.13 */
FIXED c; /* fixed: Q12.15, instrument */
c=a*b /* fixed: saturate */
}
It's this code your edit and maintain. If you "#define FIXED16 float"
its the original float code. If you run it thru the float-fixed compiler
it pickups the "fixed:" keywords in the comments and automatically works
out the shifts, handles rounding and saturation. It spits out machine
generated fixed point C code that is then passed to gcc. The
"instrument" keyword dumps a text file of values so you can work out
(manually or automatically) an appropriate scaling.
The machine generated fixed point code might look bad but will compile
OK. That's OK as you don't edit it manually. I've seen this approach
for C to VHDL "compilers".
The above is a trivial example, not sure how it would handle something
like the fixed point IIR filter example I documented here:
http://www.rowetel.com/blog/?p=1245
Cheers,
David
On Wed, 2013-03-06 at 09:32 -0700, Steve Strobel wrote:
> David Rowe <da...@rowetel.com> wrote:
> However that does present an interesting challenge. Maybe
> there is a
> way to "engineer" or automate fixed point work so that it's
> more like
> "running a compiler" than hand crafting.
>
>
>
> I like that idea a lot. In the (small amount of) fixed point work I
> have done, the choice of how many bits of resolution are needed has
> been a manual process and relatively straightforward (with few
> choices, usually 8, 16 or 32 bits unless using specialized hardware).
> The more difficult issue has been scaling (through bit shifts) the
> values to maintain as much resolution as possible without
> overflowing. Maybe something could be built on top of the existing
> feedback directed optimization facilities in GCC that would record the
> max values at each stage of the calculations and use that to adjust
> the scaling factors for later builds.
>
>
> Or rather than using the compiler, a customized math library (maybe a
> C++ class with overloaded operators that would minimize the changes
> needed to the rest of the code) could record the max values and
> provide them in a format that could control the scaling. I am
> thinking of something like a #define for each arithmetic operation
> that would indicate the number of bit shifts needed. The file of
> #define values could be included with the source code so most folks
> wouldn't need to do anything different to compile codec2, but after an
> algorithm change it could be updated.
>
>
> On target platforms that support saturation arithmetic without a big
> speed penalty, it might be worth choosing scaling factors that
> occasionally cause saturation because the increased resolution might
> more than make up for the error caused by the saturation. On targets
> that don't support saturation arithmetic, I suspect that overflow will
> need to be avoided at all costs, as it usually (in my experience)
> causes really nasty sounding results.
>
>
> Steve
>
>
>
>
> --
> Steve Strobel
> Link Communications, Inc.
> 1035 Cerise Rd
> Billings, MT 59101-7378
> (406) 245-5002 ext 102
> (406) 245-4889 (fax)
> WWW: http://www.link-comm.com
> MailTo:steve.stro...@link-comm.com
>
> ------------------------------------------------------------------------------
> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
> Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
> endpoint security space. For insight on selecting the right partner to
> tackle endpoint security challenges, access the full report.
> http://p.sf.net/sfu/symantec-dev2dev
> _______________________________________________ Freetel-codec2 mailing list
> Freetel-codec2@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
------------------------------------------------------------------------------
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
endpoint security space. For insight on selecting the right partner to
tackle endpoint security challenges, access the full report.
http://p.sf.net/sfu/symantec-dev2dev
_______________________________________________
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
