2011-01-26 20:47:27     compiling toolchain with --enable-fixed-point

Document created by Aaronwu Employee on Oct 16, 2013
Version 1Show Document
  • View in full screen mode

2011-01-26 20:47:27     compiling toolchain with --enable-fixed-point

Peter Leijen (NEW ZEALAND)

Message: 97709   

 

Dear all,

 

I'm using a bf537-EZ-Kit lite to perform some signal image processing, the camera that i'm working with is ethernet based so i'm running uClinux on the blackfin (to avoid having to program ethernet drivers/protocol). Currently i'm using floats, sqrtf and atan2 from the standard math.h library to perform all the calculations.

However this is too slow! i want to make use of the blackfins fixed point arithmetic unit using either 16.16 or 24.8 depending on the loss of resolution in the final images. I found documentation on the web referring to a __Accum data type and the <stdfix.h> library which seems suitable (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf).

 

However when i compile a simple test program using bfin-uclinux-gcc:

 

# file: fractTest2.c

#include <stdio.h>

#include <stdfix.h>

 

int main() {

  

    _Accum accumVar = 10.056k;

  

    printf("%K\t\n", accumVar);

  

}

 

i get the following

 

peter@peter-laptop:~/SRS/code$ bfin-uclinux-gcc fractTest2.c

fractTest2.c: In function ‘main’:

fractTest2.c:6: error: fixed-point types not supported for this target

peter@peter-laptop:~/SRS/code$ bfin-uclinux-gcc --version

bfin-uclinux-gcc (ADI-2010R1-RC4) 4.3.5

Copyright (C) 2008 Free Software Foundation, Inc.

This is free software; see the source for copying conditions.  There is NO

warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

peter@peter-laptop:~/SRS/code$ uname -a

Linux peter-laptop 2.6.32-27-generic #49-Ubuntu SMP Wed Dec 1 23:52:12 UTC 2010 i686 GNU/Linux

 

This has me confused as the blackfin processor programming reference manual clearly states the it can handle fixed point arithmetic. I've tryed including the flastfloat library however this is still too slow for my application.

 

Is there a way of defining custom fixed point data types, sqrt and atan2 functions in C? Or a library that needs to be linked in at compile time?

I'm currently trying to build my own cross compiler with the configuration flag --enable-fixed-point however i'm not having very much luck.

 

Can anybody help?

 

Thanks in advance Peter

QuoteReplyEditDelete

 

 

2011-01-26 20:53:59     Re: compiling toolchain with --enable-fixed-point

Mike Frysinger (UNITED STATES)

Message: 97710   

 

just because something is labeled "fixed point" does not mean they are the same thing.  if you want to use the fixed point aspects of the Blackfin, then you should use the fixed point api.

 

you can find documentation in the wiki:

http://docs.blackfin.uclinux.org/doku.php?id=toolchain:built-in_functions

 

you probably should look at the -mfast-fp option first:

http://docs.blackfin.uclinux.org/doku.php?id=optimization

QuoteReplyEditDelete

 

 

2011-01-26 22:09:24     Re: compiling toolchain with --enable-fixed-point

Peter Leijen (NEW ZEALAND)

Message: 97711   

 

Thanks for the reply Mike,

 

The information you've provided is helpfull. However i've already looked at these as an option.

 

The build_in_functions in particular the fract16 and fract32 stuff is all in 1.15 or 1.31 format meaning that i can't represent numbers greater then 1 or less then -1. In my application im dealing with 16bit data i.e. the data starts life as a short int. A simple cast to float and then conversion to fract16 leads to overflow. To prevent this i'd need to divide my data by 0x8000 or something similar, i read this somewhere in a forum. But then what's the point in using fract16 if i need to scale all my data before hand?

 

Linking in the 'fast-fp' library does halve my computation time but it is still not fast enough. I haven't played with the -O compiler flag yet...I'll do that now. My supervisor is adement on me getting the fixed point arithmetic working.

 

Thanks again Peter.

QuoteReplyEditDelete

 

 

2011-01-26 22:24:48     Re: compiling toolchain with --enable-fixed-point

Mike Frysinger (UNITED STATES)

Message: 97712   

 

these builtins and formats are what you were referring to when you said the PRM.  they are the only types we have optimized things for (1.15, 1.31, and 9.31).  if these types arent sufficient for your needs, then you'll have to write your own code.

QuoteReplyEditDelete

 

 

2011-01-27 04:38:01     Re: compiling toolchain with --enable-fixed-point

Steve Kilbane (UNITED KINGDOM)

Message: 97720   

 

If you're trying for performance, you really should be using -O (or one of the higher optimization flags). Whatever the compiler produces due to other switches will then be dramatically improved by the optimizer.

 

Fixed-point support (in terms of _Accum and _Fract) isn't just a matter of a compiler switch or rebuilding the compiler, because TR18037 also requires support for a large number of new arithmetic conversions and additional functions, and this requires a lot of additional run-time library support. To the best of my knowledge, that library hasn't been implemented for GCC yet.

 

If you're able to get access to VisualDSP++, you may find that the forthcoming VisualDSP++ 5.0 Update 9 fulfils your requirements, since it introduces _Accum and _Fract support. However, the VDSP++ implementation applies a (TR18037-conforming) interpretation of those types that maps to the support that Blackfin has, i.e. s1.15, s1.31 and s9.31, and the corresponding unsigned types; you don't get arbitrary precision.

 

As Mike says, you can roll your own (for years, VDSP++ has provided C++ classes for fract), and the built-in functions that GCC supports can help considerably here, since they'll give you both the performance and the saturation semantics for free.

 

 

 

steve

Attachments

    Outcomes