On Wed, Jan 30, 2013 at 9:34 PM, Albert Cahalan <[email protected]> wrote:
>
> 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 was hoping to swap out the math library without having to edit the codec2
source much, so operator overloading would be essential. I really doubt
anyone upstream would be interested in a patch that replaced all of the
operators with explicit function calls.
> 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 wasn't suggesting that codec2 become a C++ project in general. I just
wanted to have the option to compile the C files using the C++ compiler so
I could make use of the operator overloading. I also tried
(unsuccessfully) to pass "-x c++" to configure. ABI consistency doesn't
matter to me anyway, as firmware updates for my embedded system include an
image of the whole system.
> > I am working on a Blackfin (16-bit fixed point) DSP.
>
> I used to work on the SHARC.
I did too. We used a few of them linked together through their TDM
interfaces to handle a network of audio devices, all controlled by a
Coldfire running a touchscreen GUI. But the lure of uClinux took us to
Blackfin. Overall it works well, but the lack of FPU is limiting in some
cases like this one, and the lack of a MMU means that memory fragmentation
can be a problem.
> 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.
>
I already tried the ”-mfast-fp” option which does at least some of those
things. In combination with some other compiler options I was able to
speed things up maybe 20% or so, but it was still running codec2 only about
1/7th of real time.
> Hacking the library would help, but ideally you'd hack gcc itself.
>
I hadn't really considered that. I suppose the cleanest way to accomplish
it would be to add proper support for the "half float" datatype, but for a
one-off test I could just hack the float and double routines (maybe with a
command line switch) to make them faster. I am afraid that is far beyond
the scope of what I was planning to do. It might be easier to tackle the
fixed-point port of codec2 ;)
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:[email protected]
------------------------------------------------------------------------------
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
