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

[Jean-Marc Valin]

> For the persistent storage, the only change that I have made is to 
> MAX_CHARS_PER_FRAME, which is set to 2000 in bits.c.  I changed bits.c to 
> set this value only if it was not already defined, and then put my own, much 
> smaller value in config.h.

Yeah, I think I'll add an option like that.

> 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.

> 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).

> 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?

> Note that I also moved the "if (!st)" check to before st-stack is set, since 
> a write to a bad location would occur otherwise.

Makes sense.

	Jean-Marc

-- 
Jean-Marc Valin <Jean-Marc.Valin at USherbrooke.ca>
Universite de Sherbrooke