On Wed, Jan 30, 2013 at 6:55 PM, Steve Strobel
<[email protected]> wrote:
> On Tue, Jan 29, 2013 at 10:38 PM, Albert Cahalan <[email protected]> wrote:

> I took a small step toward this a month or so ago, but for a completely
> different reason.  I planned to replace "float" and "double" with typedefs,
> then provide a way to optionally swap in a C++ floating point library to do
> the calculations.  The effort stalled when I realized that codec2 is
> compiled as C rather than C++ and I couldn't make it call the C++ math
> library.

The details matter, but you can certainly call C++ from C.
You won't get the operator overloading, but functions work.
On the C++ side, use extern "C" to provide a C interface.
I think the result will be really ugly, but not any worse than
the kiss_fft.c fixed-point macros. You could even use those.

I strongly discourage having a C++ ABI. It would be unstable.
(history shows that betting on C++ ABI stability is very dumb)
It would also be difficult to call from most languages.

> I didn't find the configure.ac file and didn't pursue it any
> further (if the configure.ac file isn't in the Subversion repo, maybe it
> could be added?).

Heh. You too. :-/

> I am working on a Blackfin (16-bit fixed point) DSP.

I used to work on the SHARC. From that comes the TigerSHARC
and then the Blackfin. What happened to the 40-bit FPU?
The SHARC was great for radar, sonar, CAT scans, MRI scans, etc.
Analog Devices still sells the TigerSHARC. For $184.49 (per-device
for 1000 to 4999) you get a half megabyte of on-chip memory and
you can do 4 billion floating-point multiply-add operations per second.

Wait, the SHARC is still available. For just $11 per device in
amounts as low as 100, the ADSP-21375 delivers 1596 MFLOPS.
It's not even a BGA; it is a 208 lead LQFP E_Pad.

Back in my day, processors were faster...   <-- should not be

> GCC provides floating
> point emulation libraries, but they are way too slow to run Codec2 realtime.

I think the problem is that gcc is trying too hard. It's probably giving
you 100% IEEE-compliant floating-point using the standard format.

The first thing to do is to say that all NaN and Inf values, on input
or output, invoke undefined behavior. There is only one rounding
mode, and there are no exceptions.

You could also cheat with the range. For example, anything with
an absolute value greater than 0x7fffffff invokes undefined behavior.

You could reduce the fraction bits from 23 to 15 or 16. Not that I
like this much, but you could even turn denormals into zeros.

Hacking the library would help, but ideally you'd hack gcc itself.
If you chop your expectations down enough, it becomes reasonable
to have gcc generate code that doesn't make function calls to
to the math. Think of how long long is handled on 32-bit x86.
It used to always do calls into a library, but now is rarely does.
Inlining means that the operations can be interleaved and the
temporary components can stay in registers.

The in-memory format need not be standard.

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan
_______________________________________________
Freetel-codec2 mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Reply via email to