search for: vararrays

Hi all ! I just learned about the Opus codec and would like to try it out on my NRF52 (Cortex-M4) target.   I've been struggling a bit with the "trival_example.c" setup but repeatedly run into "hard fault" crashes when stepping through the code. Firstly; for a "bare bone" configuration, does the following compiler directives make sense ? UDEFS =

Ok. That's a somewhat different problem, then. Devil will be in the details of what you want to do. A few options. First is to always have a standard frame pointer register available and reference off of that. Caveat: dynamic stack realignment and vararrays muck with that more than a bit. Second is what gcc is doing and reserve a register just for this in addition to the frame register. Possibly even better though is to use a plain virtual register and let the register allocator do its thing for materializing it when needed. There's a local frame...

Hi, Here's an updated resampler patch against current SVN. It includes SSE and SSE2 optimizations (the latter if included by _USE_SSE2). Best regards, Thorvald -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: speex-resampler-update.diff Url: http://lists.xiph.org/pipermail/speex-dev/attachments/20080426/e055077f/attachment-0001.txt

Is there a particular reason why CELT grabs 100KB of stack immediately? Is that really required or can that be trimmed down some/a lot? -a

...ation is supposed to happen. However, the following call chain > (obviously)  cause a crash: > > opus_encode(..)-> > opus_encode_native(..)->ALLOC_STACK->opus_alloc_scratch(..)->opus_alloc(..) NONTHREADSAFE_PSEUDOSTACK requires a working allocator. You should select either vararrays or alloca(). Both should work on any gcc-based Cortex-M toolchain. (For that matter, malloc() and free() should work fine too, unless you have other reasons to avoid them)

...n 09/26/2012 12:00 AM, Jim Grosbach wrote: > Ok. That's a somewhat different problem, then. Devil will be in the details of what you want to do. A few options. First is to always have a standard frame pointer register available and reference off of that. Caveat: dynamic stack realignment and vararrays muck with that more than a bit. Second is what gcc is doing and reserve a register just for this in addition to the frame register. Possibly even better though is to use a plain virtual register and let the register allocator do its thing for materializing it when needed. There's a local frame...

We already divided out our classes as you did for ARM. The problem here is that we have a store/load byte/halfword to/from a Frame object. We know at that time that it's not going to be possible to store it using SP because there is only such instructions for store/load of a word. What we would want to do is to move SP into a Mips 16 register and then do a indexed load/store off of that