similar to: Blackfin inline assembly for fixed math

Most asm statements clobber ASTAT bits (shifts, maxes, etc...) but do declare the register as clobbered. Same thing with CC in a few places. Some places make an attempt at clobbering some hardware loop registers, but it's very incomplete compared with how many asm statements actually use hardware loops. Signed-off-by: Mike Frysinger <vapier at gentoo.org> --- libspeex/bfin.h

These were used because the entropy coder originally came from outside libcelt, and thus did not have a common type system. It's now undergone enough modification that it's not ever likely to be used as-is in another codec without some porting effort, so there's no real reason to maintain the typedefs separately. Hopefully we'll replace these all again somedate with a common set

Hi, ? Is there a fix for this issue??? ---> http://permalink.gmane.org/gmane.comp.audio.compression.speex.devel/2959 ? I am seeing the same thing when I compile speex in visualdsp ? These are the errors I get from using the assembly version of vq_nbest: ? ..\..\..\..\algorithms\voice\speex\src\vq.c [Error ea5004] "C:\Users\coder\AppData\Local\Temp\acc22e8547f000\acc22e8547f001.s":482

Hi, I am looking into fixed-point code of the CELT decoder for real-time application. Here are some questions.. [1] array, window[] The array, window[] is being initialized from a function below in modes.c. This array is being initialized differently for the decoder, depending on frame size and sampling freq. of the bitstream .. Could you provide us with fixed-point code for initialization of

Hi, I have a general question on LoopUnswtich pass. Consider the following IR snippet: define i32 @test(i1 %cond) { br label %loop_begin loop_begin: br i1 %cond, label %loop_body, label %loop_exit loop_body: br label %do_something do_something: call void @some_func() noreturn nounwind br label %loop_begin loop_exit: ret i32 0 } declare void @some_func() noreturn After running

> I am trying to port speex lib to Blackfin processor. > I am using VisualDSP++ 4.0. I've never used VisualDSP++ 4.0. All the development on Blackfin has been done with gcc, which may explain some problems with the inline asm. Does VisualDSP++ support a syntax close to what gcc uses (with constraints) or more like the MS compilers. > If I am compiling source codes with using

Hello! I'v downloaded speex lib 1.1.11.1. I am trying to port speex lib to Blackfin processor. I am using VisualDSP++ 4.0. If I am compiling source codes with using floating point everything ok. When I am compiling with FIXED_POINT defined everything's ok and code works about two times faster. But when I am defining BFIN_ASM I am getting several compiling errors in Blackfin assembler

Hello, in celt/celt_encoder.c line 369, the 'b' argument to MAX16 can sometimes be greater than what can be represented by a 16bit integer. The default definition of MAX16 is type-less, but I am working on an architecture with hardware support for min/max of 16bit. Changing the default definition to take advantage of this hardware changes the result of that computation. Please consider

There is a problem in speex_preprocess_ctl. Both speech_prob_start and speech_prob_continue are set to 327.67 for all input values except 0 which results in 0. This is in floating point mode. I think the included patch fixes the problem. Mikael -------------- next part -------------- Index: libspeex/preprocess.c =================================================================== ---

Did you check it against the trunk in SVN? If it's not applied, and you can hook Jean-Marc up with an email address like yours, I'm sure he will get right on it. :) Tom Mihai Balea <mihai@hates.ms> wrote: > > Hi all, > > Did anything happen to this patch? > It seems to me that it fixes a valid issue, but I'm not an expert. > Anyways, I didn't see

Hi there, Let's have this C code: unsigned long div(unsigned __int128 n, unsigned long d) { return n / d; } I would assume that the divq is the perfect match here. But the compiler generates the code that calls the __udivti3 procedure which performs 128-bit by 128-bit division. Why is divq not used here? - Paweł -------------- next part -------------- An HTML attachment was scrubbed...

I checked it against the latest code in the git repository and it wasn't there. Mihai PS: if JM wants a @hates.ms address, I could prolly hook him up. Especially if he throws in some VAD code that's not "a hack" :) On Nov 5, 2007, at 2:08 PM, Tom Grandgent wrote: > Did you check it against the trunk in SVN? > > If it's not applied, and you can hook Jean-Marc up

I realize this is ancient history, but I am trying to compile Ver 8.1 (from the download page) using Fixed Point and am getting compile errors as follows: argument of type "celt_sig *" is incompatible with parameter of type "celt_int16 *" libcelt81_orig_DSP/libcelt celt.c line 321 1304524612394 19769 argument of type "celt_sig *" is incompatible

Is this a common warning? The decoder doesn't return an error on it, but I see it a lot in my test application on windows. It is non existent on my linux box. I haven't tried mingw yet. please note that I'm using visual studio 2008 w/the vcproj that Bjoern Rasmussen made for 0.5.2 (w/some file references removed) at the moment and it is giving a lot of C4554 warnings

Hi. I am glad to inform everyone here that support for decoding using libcelt was just pushed to ffmpeg. It raised a few API questions or issues: * At least while it's experimental, having a constant in the library for the supported bitstream version would probably be useful. Something like that comes to mind: extern celt_int32 celt_bitstream_version; or, even better: int

We were trying to normalize bands that didn't actually exist (e.g., the last band with 320-sample frames at 32kHz). Thanks to John Ridges for the report. --- libcelt/celt.c | 24 +++++++++++++++++------- 1 files changed, 17 insertions(+), 7 deletions(-) diff --git a/libcelt/celt.c b/libcelt/celt.c index 31d35f8..287c720 100644 --- a/libcelt/celt.c +++ b/libcelt/celt.c @@ -1137,6 +1137,7

Gents, I am getting the following compile error on V11.1 "declaration may not appear after executable statement in block". This occurs in two places in celt.c. ============================================================================ ==================== #ifdef FIXED_POINT #ifndef DISABLE_FLOAT_API CELT_STATIC int celt_encode_with_ec_float(CELTEncoder * restrict st, const

The patch prevents KEIL MDK compile warnings, like:   warning:  #1035-d: single-precision operand implicitly converted to double-precision Actually ARM Cortex-M4F has only a *single precision* (float) FPU. It's suit for all platforms. See the comment at the begin of patch file. Sincerely Forrest Zhang -------------- next part -------------- Specify the floating point constant with single

Hi JM, When porting my project to the Mac, I found that the definition for "celt_int16" and "celt_uint16" are wrong for the MacOS X Framework in celt_types.h, and need to be changed to "int16_t" and "u_int16_t" respectively. Just thought you ought to know. John Ridges

Hello, in this commit in celt_encoder.c https://git.xiph.org/?p=opus.git;a=commitdiff;h=652c4559f593d3aad78bd5c85a216eeae7859429 I see the note: + /* We should never see NaNs here. If we find any, then something really bad happened and we better abort + before it does any damage later on. If these asserts are disabled (no hardening), then the table + lookup a few lines below