search for: v5e

It would be great to get some idea of what chips and DSPs people have tried to compile Speex for, and what success they've had. So, if you've tried Speex on a chip, could you take a second to fill in the following and post it to the list? Chip Name: Speex Version: Floating or Fixed: Encode, Decode, Both or Simultaneous: MIPS (if known): Other comments: Many thanks, Gerv

...ex running. I'm sure there are others (especially > the float version should really run on any chip with an FPU). > > float: > x86/x86-64 (SSE assembly optimizations provided) > PowerPC > SPARC I've had floating decoding running on a C5510. > fixed: > ARM (v4 and v5E) (assembly optimizations provided) > Blackfin (assembly optimizations provided) Any chip in the Blackfin range, or just certain ones? > TI C6x > TI C55x Can you be more specific about which C55x chips it has run on? > TI C54x (but still too slow due to compiler issues) Are these al...

...rocessor. If you >> would find the opposite to be true (ie that a 64 bit implementation is >> faster on, say, a 32 bit ARM CPU) then perhaps we should reconsider. >> > > Doesn't ARMv6 have a dual signed 16x16->32 multiply with a 64-bit > accumulator (SMLALD)? Even v5E should have a single 16x16->32 with a 64-bit > accumulator (SMLALBB). I would think a 64-bit version could be made pretty > fast on 32-bit ARM, without even resorting to SIMD. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/piperma...

...8% 8000 kbit/sec Encoder - 47% Decoder - 4% 11200 kbit/sec Encoder - 65% Decoder - 4.1% 15000 kbit/sec Encoder - 53% Decoder - 4.2% Except 11200 mode it can work on 48 MHz STM32 USB Access Line. (11200 probably can work in non full duplex application). Version for ARM v5E (STR9) is faster for about of 25% for comparable processor's frequencies, by using of DSP commands. Version for ARM v4 (STR7, LPC21XX/23XX/28XX) can work even on 60 MHz. (but not all speex modes. Just 6,8,15). Here is Measurements of performance for LPC2138 - 60 MHz. 4000 kbit/sec...

...ehavior. Index: lib/Support/TargetParser.cpp =================================================================== --- lib/Support/TargetParser.cpp (revision 257090) +++ lib/Support/TargetParser.cpp (working copy) @@ -401,6 +401,7 @@ .Case("v5", "v5t") .Case("v5e", "v5te") .Case("v6j", "v6") + .Case("v6l", "v6") .Case("v6hl", "v6k") .Cases("v6m", "v6sm", "v6s-m", "v6-m") .Cases("v6z", "v6zk",...

Right, there shouldn't be a problem with undefined behavior. That said, a 64 bit implementation will work very well - in fact that's how it was done originally. The reason for the current implementation is to minimize 64-bit operations in order to improve performance on limited-width architectures. This functions gets used extensively, and I think the current implementation is faster on

...now all the details, but here's a (partial) list of archs on which I've heard of Speex running. I'm sure there are others (especially the float version should really run on any chip with an FPU). float: x86/x86-64 (SSE assembly optimizations provided) PowerPC SPARC fixed: ARM (v4 and v5E) (assembly optimizations provided) Blackfin (assembly optimizations provided) TI C6x TI C55x TI C54x (but still too slow due to compiler issues) Jean-Marc Le dimanche 04 septembre 2005 ? 09:08 +0100, Gervase Markham a ?crit : > It would be great to get some idea of what chips and DSPs people...

...is faster on a 32 or 16 bit processor. If you > would find the opposite to be true (ie that a 64 bit implementation is > faster on, say, a 32 bit ARM CPU) then perhaps we should reconsider. Doesn't ARMv6 have a dual signed 16x16->32 multiply with a 64-bit accumulator (SMLALD)? Even v5E should have a single 16x16->32 with a 64-bit accumulator (SMLALBB). I would think a 64-bit version could be made pretty fast on 32-bit ARM, without even resorting to SIMD.

I have one more question regarding ARM codegen support. Is it possible to pass a flag to Codegen to generate only ARMv5 instructions and not to use instructions from higher versions, ( In other words, is this version specific information present in LLVM codegen?) Thanks Kapil On Fri, Oct 10, 2008 at 10:12 PM, Chris Lattner <clattner at apple.com> wrote: > > On Oct 10, 2008, at

...lementation is faster on a 32 or 16 bit processor. If you would find the opposite to be true (ie that a 64 bit implementation is faster on, say, a 32 bit ARM CPU) then perhaps we should reconsider. Doesn't ARMv6 have a dual signed 16x16->32 multiply with a 64-bit accumulator (SMLALD)? Even v5E should have a single 16x16->32 with a 64-bit accumulator (SMLALBB). I would think a 64-bit version could be made pretty fast on 32-bit ARM, without even resorting to SIMD. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/opus/attach...

> You assume triples make sense. That's the first mistake everyone does > when thinking about triples. :) I know they don't make sense in many corner cases, but I think discarding logic where it *does* exist is a mistake. > AFAIK, "ARMv7B" is only used by HighBank, which is no more. But that, > too, was "ARMv7A big endian". I believe it's what any

...5 at fsYsPOx_Tb0l@nFJIc)fMra+#qfxAT{St#77i90Zdpjq~t_yJj3TDF-IBG`!PR0 zm;7V9f&nNm3<UDE5--dz7Jf0x@&WR4Jj_7^WI at 7D`25QN96W1WqpgO`Zqk<3V<C*m z<9?yPO8{bs0tqr<RVDhZ2P_*|KE28=r%m1^({q{vEB)InV=^31T@=xoAEEc|X3DI3 zDpMflXu$L`i;$@9PaNLMwD>FG`$x=pn+!j~)pa?gIvR#nlh$8Oj#shQ#5mxt2Bm6! zv5EUwbCnFSn4$$}&A4;x0(647C}&hEAFXk5HNb3gvR1P{P4Qz|b_ErclO+I9P8f*% zdN^ULOhrYbuwr6y=Q;dN*Ka^5l6jNwg$pQ3KUehaZ=Q?pwn$9rE>lDkK*a*+_4RP~ zp|bY-gxo&2GXt4bj{}H60ZRdGOPYOfvv(=xJXbR6uQ<6pE}uPoizGvvvH-|39;l`r zfX?G~ILDhb8l_$vT at TV0D)ZEWS*CZ|m0cYV4<4k2#I!5qCZme#VxZ?8Yg%&E+E=n3 zw&n...