search for: pdiv32_16

...ot;A1 = A1 >>> 15;\n\t" "%0 = (A1 += %2.L*%1.H);\n\t" "%0 = %0 + %4;\n\t" : "=&W" (res), "=&d" (b) : "d" (a), "1" (b), "d" (c) : "A1" ); return res; } #undef PDIV32_16 static inline celt_int16 PDIV32_16(celt_int32 a, celt_int16 b) { celt_int32 res, bb; bb = b; a += b>>1; __asm__ ( "P0 = 15;\n\t" "R0 = %1;\n\t" "R1 = %2;\n\t" //"R0 = R0 + R1;\n\t" "R0 <&...

...ot; BFIN_HWLOOP0_REGS BFIN_HWLOOP1_REGS ); } diff --git a/libspeex/fixed_bfin.h b/libspeex/fixed_bfin.h index aa26f6a..9eb21e3 100644 --- a/libspeex/fixed_bfin.h +++ b/libspeex/fixed_bfin.h @@ -36,6 +36,8 @@ #ifndef FIXED_BFIN_H #define FIXED_BFIN_H +#include "bfin.h" + #undef PDIV32_16 static inline spx_word16_t PDIV32_16(spx_word32_t a, spx_word16_t b) { @@ -57,7 +59,7 @@ static inline spx_word16_t PDIV32_16(spx_word32_t a, spx_word16_t b) "%0 = R0;\n\t" : "=m" (res) : "m" (a), "m" (bb) - : "P0", "R0&qu...

...in ASM version), and wondered why the return value of the function inside 'fixed_bfin.h' is of type 'spx_word16_t', but the local variable 'res' which is returned by this function is of type 'spx_word32_t'. Is this a trick of optimization or a bug? (Same question for PDIV32_16 and MAX16, too!) best regards, Frank -----Urspr?ngliche Nachricht----- Von: "Jean-Marc Valin" <jean-marc.valin@usherbrooke.ca> Gesendet: 02.02.08 06:26:08 An: speex-dev <speex-dev@xiph.org> Betreff: Re: FW: Re: [Speex-dev] Problem with Blackfin assembly optimizations -- bu...

...wondered why the return value of the function inside > 'fixed_bfin.h' is of type 'spx_word16_t', but the local variable > 'res' which is returned by this function is of type 'spx_word32_t'. > Is this a trick of optimization or a bug? (Same question for > PDIV32_16 and MAX16, too!) Neither (AFAIK). The idea is that sometimes gcc does silly/counter-intuitive things when I specify a 16-bit variable as a constraint. That way, I force the top 16 bits to be zero. Jean-Marc > best regards, Frank > > > -----Urspr?ngliche Nachricht----- Von: "J...

...turn value of the function inside >> 'fixed_bfin.h' is of type 'spx_word16_t', but the local variable >> 'res' which is returned by this function is of type 'spx_word32_t'. >> Is this a trick of optimization or a bug? (Same question for >> PDIV32_16 and MAX16, too!) > > Neither (AFAIK). The idea is that sometimes gcc does > silly/counter-intuitive things when I specify a 16-bit variable as a > constraint. That way, I force the top 16 bits to be zero. > > Jean-Marc > >> best regards, Frank >> >> &gt...

...e function inside >>> 'fixed_bfin.h' is of type 'spx_word16_t', but the local variable >>> 'res' which is returned by this function is of type 'spx_word32_t'. >>> Is this a trick of optimization or a bug? (Same question for >>> PDIV32_16 and MAX16, too!) >> Neither (AFAIK). The idea is that sometimes gcc does >> silly/counter-intuitive things when I specify a 16-bit variable as a >> constraint. That way, I force the top 16 bits to be zero. >> >> Jean-Marc >> >>> best regards, Frank &gt...

...gt;>>> inside 'fixed_bfin.h' is of type 'spx_word16_t', but the local >>>> variable 'res' which is returned by this function is of type >>>> 'spx_word32_t'. Is this a trick of optimization or a bug? (Same >>>> question for PDIV32_16 and MAX16, too!) >>> Neither (AFAIK). The idea is that sometimes gcc does >>> silly/counter-intuitive things when I specify a 16-bit variable >>> as a constraint. That way, I force the top 16 bits to be zero. >>> >>> Jean-Marc >>> >>&gt...