[Speex-dev] Speex on TI C6x, Problem with TI C5x Patch

[Jim Crichton]

>> For the scratch stack, I replace the fixed values in nb_encoder_init and
>> nb_decoder_init with constants that I defined in config.h.  Jamey Hicks
>> original C5x patch had some test code in stack_alloc.h to detect working
>> stack overflow.  Maybe something similar could be done to measure the 
>> peak
>> stack usage, enabled by a debug switch.  Then, for a space critical
>> application, it would be easy to measure the stack requirement for a 
>> given
>> operating mode, and set the size (manually) accordingly.
>
> I'm not sure how you could detect that without carrying the stack limit
> everywhere though. What I would suggest instead is just to fill the
> stack with 0xdeadbeef and then look up to what address you have it
> overwritten.

I was talking about adding some peak detect side effect to the ALLOC macro. 
But, of course, painting the stack is a lot simpler, and can be done with no 
performance penalty.

>> According to this standard, an allocate call is made to an algorithm, and
>> the algorithm fills in a table of required blocks (size, alignment, and
>> scratch/persistent type).  The system allocates these blocks, and calls 
>> the
>> algorithm init function, with the same memory table, now including the 
>> base
>> addresses.  Now, these addresses have to get into Speex somehow.  Since I
>> did not want to change the API, I have resorted to the kludge of 
>> declaring
>> global variables, which I initialize based on the allocated memory 
>> blocks.
>> My alloc routines then look at the global variables, similar to the way
>> calloc works.
>
> What I would suggest is to have a c55-specific function that allocates
> enough memory for everything and then overload speex_alloc to return
> pointers to that area (in a way similar to the way my pseudo-stack
> works).

Yes, that is what I am doing.  The global variables to which I referred are 
pointers to the next free location and to the end (for overflow detection, 
debug only) of the pre-allocated block.  Realloc and Free do not do 
anything, because the whole block gets freed outside of Speex when an 
instance (for multichannel) of the algorithm is destroyed.

>> This does not solve the problem of distinguishing persistent and scratch
>> storage.  To do this, I added a speex_alloc_scratch routine, which uses a
>> different memory block than speex_alloc.  This does force a change to
>> nb_encoder_init, etc.  At the moment, the code looks like this:
>
> I'm not sure how your environment defines scratch space. What's the
> difference?

Scratch space does not need to be preserved between calls.  In an 
environment with multiple algorithms, or multiple instances of an algorithm, 
this space can be reused, as long as there is no preemption (each algorithm 
runs to completion).  On a DSP like the C64x (up to 1000 MIPs now), memory 
can be more of a limiting factor than MIPs, in determining the number of 
channels which can be supported.

An alternative is to fall back to the C-stack, but that makes debugging more 
difficult, and it is less efficient if there are other algorithms present 
which do allocate scratch blocks in the XDAIS way (because that scratch 
space could be used for Speex).

- Jim Crichton