[Speex-dev] Speex on TI C6x, Problem with TI C5x Patch
Jean-Marc.Valin at USherbrooke.ca
Wed May 25 14:25:48 PDT 2005
> 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
> 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
> 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
> 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.
Jean-Marc Valin <Jean-Marc.Valin at USherbrooke.ca>
Universite de Sherbrooke
More information about the Speex-dev