similar to: [PATCH 1/2] arm: Use the UAL syntax for ldr<cc>h instructions

This is required in order to build using the built-in assembler in clang. --- I squashed the two changes since it would break the normal gcc build otherwise. --- celt/arm/arm2gnu.pl | 2 ++ celt/arm/celt_pitch_xcorr_arm.s | 18 +++++++++--------- 2 files changed, 11 insertions(+), 9 deletions(-) diff --git a/celt/arm/arm2gnu.pl b/celt/arm/arm2gnu.pl index eab42ef..5c24758 100755 ---

On Fri, 7 Feb 2014, Timothy B. Terriberry wrote: > Martin Storsjo wrote: >> This is required in order to build using the built-in assembler >> in clang. > > These patches break the gcc build (with "Error: bad instruction"). Ah, right, sorry about that. > Documentation I've seen is contradictory on which order ({cond}{size} or > {size}{cond}) is correct.

Hello, This is a first patch which add macros for ARMv5E. Also, I copy headers from other files and add company name, tell me if I'm wrong. Also, if you have any question or comment about it, feel free to contact me. Best regards, -- Aur?lien Zanelli Parrot SA 174, quai de Jemmapes 75010 Paris France -------------- next part -------------- diff --git a/celt/fixed_arm5e.h

Hi, I had the following errors when compiling the library for Cortex-m4 (-mcpu=cortex-m4) using the GNU compiler for ARM (gcc-arm-none-eabi-4_8). CPPAS celt/arm/celt_pitch_xcorr_arm-gnu.locelt/arm/celt_pitch_xcorr_arm-gnu.S: Assembler messages:celt/arm/celt_pitch_xcorr_arm-gnu.S:299: Error: thumb conditional instruction should be in IT block -- `ldrgt

Hello, I am trying to build a speex library file for armv6 on intel MAC OS. I've also put -enable-arm5e-asm whether arm5e-asm works or not. ./configure -prefix=/Users/mijin/temp -disable-shared -enable-static - enable-fixed-point -enable-arm5e-asm This gives below errors. gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I../include -I.. -g - O2 -fvisibility=hidden -MT cb_search.lo -MD

- Use MAC16_16 macros instead of (sum += a*b) and unroll a loop by 2. It increase performance when using optimized macros (ex: ARMv5E). A possible side effect of loop unroll is that i don't check for odd length here. - Add NEON version of FIR filter and autocorr -- Aur?lien Zanelli Parrot SA 174, quai de Jemmapes 75010 Paris France -------------- next part -------------- diff --git

Please ignore my previous mail and patch, there is a new version :). Patch changes are: - Use MAC16_16 macros instead of (sum += a*b) and unroll a loop by 2. It increase performance when using optimized macros (ex: ARMv5E). A possible side effect of loop unroll is that i don't check for odd length here. - Add NEON version of FIR filter and autocorr - Add a section in autoconf in order to

Thanks for your prompt and helpful reply. In FLOAT_DIVU() it hangs at the following: while (a.m >= b.m) { e++; a.m >>= 1; } for the case where a and b are both zero (yes, division by zero). This happens from mdf.c: leak_estimate = FLOAT_EXTRACT16(FLOAT_SHL(FLOAT_DIVU(st->Pey, st->Pyy),14)); where st->Pey and st->Pyy are both zero, which happens for the

Hi, I am getting the following dump while trying to build for arm ./configure --prefix=/root/dump --host=arm-linux --with-gnu-ld --disable-static --enable-fixed-point --enable-arm-asm -enable-arm5e-asm configure: WARNING: unrecognized options: --enable-arm-asm Type "make; make install" to compile and install Speex root at rony-ubuntu:~/speex# make make all-recursive make[1]:

Hi Ted, Thanks a lot for this analysis. > In FLOAT_DIVU() it hangs at the following: > while (a.m >= b.m) > { > e++; > a.m >>= 1; > } > for the case where a and b are both zero (yes, division by zero). > This happens from mdf.c: True, that needs to be fixed even after I fix the rest. > leak_estimate =

> The plan is to form calls to these intrinsics in InstCombine. Legalizer > can expand these intrinsics if they are not legal. The expansion should > be fairly straight forward and produce code that is at least as good as > what LLVM is currently generating for these code sequence. SSAT/USAT may set the Q (saturation) flag, which might cause problems for anyone relying on explicitly

Yes those instructions exist, although they're a bit slower than the basic 16x16->32 with 32-bit accumulation (SMLABB). So I'd be surprised if the function with 64 bit accumulation would run as fast as the current code. Don't know how much we care about 16-bit platforms. And accuracy should not matter. On the other hand, a 64-bit implementation is much cleaner/shorter, which is

> I have one question: Will Speex run in realtime (both encode / decode > probably simulateusly) on Nokia 6600 --- basicaly ARM9 104MHz with Symbian > 7s after porting to its C++ or Java? I am thinking mostly about the worst > quality encoding (optionally duplex). Can this processor make it? Oh 6600 > has something about 6mb memory if I remember good. I'm not sure the

Hi, A question, How to embed inline assembly in EVC++? Can EVC link with obj file generated by pocketgcc? thanks James (sorry , last time I sent it to *.ca) On Sat, 26 Mar 2005 11:11:50 -0500, Jean-Marc Valin <Jean-Marc.Valin@usherbrooke.ca> wrote: > Hi, > > Assuming you have gcc, you can already compile with --enable-arm5e-asm > and get good results. Right now, many

Yes, regarding the unsigned to signed conversion you are right, it is implementation defined. I just had an issue a couple of years ago with a compiler which incorrectly treated unsigned overflow as undefined rather than implementation defined? Regarding the 64 bit profiling: I looked at the disassembly (gcc ?c ?S ?O2 ../opus/silk/sum_sqr_shift.c ?I../opus/include ?I../opus/celt) of the 64 bit

Do the two types have a constant integer and fractional part (ie 8.8 and 16.16), or does it vary. If it varies, is there any way to figure out where the split is for a certain variable? On May 8, 2004, at 11:28 PM, Jean-Marc Valin wrote: > Le sam 08/05/2004 à 19:30, Rib Rdb a écrit : >> is there documentation of what the various fixed point macros do, so I >> can work on

--- libcelt/Makefile.am | 6 +- libcelt/bands.c | 26 +++++++++- libcelt/bands.h | 2 +- libcelt/celt.c | 23 +++----- libcelt/pgain_table.h | 133 ------------------------------------------------- libcelt/quant_pitch.c | 117 ------------------------------------------- libcelt/quant_pitch.h | 44 ---------------- 7 files changed, 37 insertions(+), 314

Hi, I am using 1.2beta2 on a C5416 doing narrowband in the decode function I am having a problem with the execution of my program vectoring off to random interrupts that are not used. I have tracked down the error to the highpass function called in nb_decode -very close to the end of the function-context: it is called here: ln 1719 for me if (st->highpass_enabled) highpass(out,

Hmm, what these instructions do? (I know nothing about ARMs; I have some knowlege about x86 assemblers and programming). Cant we use pure standard C++ or Java? Does Speex work with fixedpoint math? (As far as I know Java on 6600 has no builtin floatingpoint, there is emulation class somewhere on the net, but it is probably painfully slow.) I do not know if this processor has builtin

I emailed Jean-Marc the arch.h about one week ago, not quite sure whether he actually received that email. Anyway, here I have an improved version of arch.h that I believe that it would be better, to use __int64 only if compiling on eMbedded Visual C++ compiler, so for any other compiler, keep it the same (use long long) ---------------------------------- Chan Kei Yuen (Kenji)