Speex dev - Jan 2006 - Compiler warnings with GCC 3.4.4 and perfomance question on a Arm 7

I am using speex on a Philips LPC2138 Arm 7 processor and have hit two
compiler warnings when using FIXED_POINT and the Arm 4 asm code.

In cb_search.c get a warning on the call to compute_weighted_codebook of:
"passing arg 2 of 'compute_weighted_codebook' from incompatible
pointer type'


In cp_search_arm4.h it is defined as:
static void compute_weighted_codebook(const signed char *shape_cb,
const spx_sig_t *r,
.....

but in cb_search.c it is defined as static void
compute_weighted_codebook(const signed char *shape_cb, const
spx_word16_t *r, .....

So it appears the arm version has arg 2 defined differently so I am
getting this error. So am I missing something or is this what it
should do ?  I am using GCC 3.4.4.

The second warning is in ltp_arm4.h in "pitch_xcorr(" getting a
warning of:
"matching constraint does not allow a register" on the   "
__asm__
__volatile__ " line.  I have no idea how to fix this warning.

Even with these errors I have gotten decoding to work YEAH!!.   It
appears to take about 10 to 11 msec to decode one frame of a wideband
file with enhancement on.   This is on a 60 mhz processor (suppose to
be about 50 MIPs).   So should it take this long to decode a frame??
If not is there something I can check?

Is using the Arm 4 asm code the correct thing for an Arm 7 processor?

Thanks
Tom

On Mon, 2006-01-23 at 10:15 -0500, tom abcd wrote:
> I am using speex on a Philips LPC2138 Arm 7 processor and have hit two
> compiler warnings when using FIXED_POINT and the Arm 4 asm code.
> 
> In cb_search.c get a warning on the call to compute_weighted_codebook of:
> "passing arg 2 of 'compute_weighted_codebook' from
incompatible pointer type'
OK, I forgot to update the ARM4 code. That should definitely be fixed
(otherwise it's not going to work).

> The second warning is in ltp_arm4.h in "pitch_xcorr(" getting a
warning of:
> "matching constraint does not allow a register" on the   "
__asm__
> __volatile__ " line.  I have no idea how to fix this warning.
can you give me more info on this?
> Even with these errors I have gotten decoding to work YEAH!!.   It
> appears to take about 10 to 11 msec to decode one frame of a wideband
> file with enhancement on.   This is on a 60 mhz processor (suppose to
> be about 50 MIPs).   So should it take this long to decode a frame??
> If not is there something I can check?
I have found the performance/MHz of ARM CPUs is extremely variable.
Given that, the results you're getting may make sense. Just be aware
that there are still a few float operations left in wideband, so you
might be hurt a bit by that.
> Is using the Arm 4 asm code the correct thing for an Arm 7 processor?
Yes.

	Jean-Marc

> OK, I forgot to update the ARM4 code. That should definitely be fixed
> (otherwise it's not going to work).
If this is not going to work then why does it work on my Arm?  Any
quick fix I can do for now?
> > The second warning is in ltp_arm4.h in "pitch_xcorr("
getting a warning of:
> > "matching constraint does not allow a register" on the  
" __asm__
> > __volatile__ " line.  I have no idea how to fix this warning.
>
> can you give me more info on this?
Not sure what info will help but here it goes...
I am using GCC 3.4.4 compiling ltp.c I get 8 warnings and all of them
seem to be when
"#define OVERRIDE_PITCH_XCORR
static void pitch_xcorr(const spx_word16_t *_x, const spx_word16_t
*_y, spx_word32_t *corr, int len, int nb_pitch, char *stack) "

is included from ltp_arm4.h
The error places the cursor on the          __asm__ __volatile__ (    
 line in the function.   I am compiling with Optimization Level 1.

I did a quick google search and found this where someone else had a
similar problem when switching from 3.2.3 to GCC 3.4.0.
http://gcc.gnu.org/ml/gcc/2004-04/msg01455.html

So what version of GCC are you using?
>
> I have found the performance/MHz of ARM CPUs is extremely variable.
> Given that, the results you're getting may make sense. Just be aware
> that there are still a few float operations left in wideband, so you
> might be hurt a bit by that.
>
Any suggestions as to which functions I should look at for the float
operations to change to Integer?  (assuming it is a simple task to
change the code from float to int or if I can copy how you change the
same kind of statements in the narrowband float to int conversion
otherwise I will probability will not figure it out and will just live
with the performance I have now.)

Thanks
Tom