[Tremor] Implementing Tremor on low-end ARM

[hb at x256.org]

On Tue, Dec 16, 2008 at 02:58:30PM -0500, Ethan Bordeaux wrote:
> Is there any reason you changed the name of so many allocations in the
> source files rather than going with a #ifdef for _ogg_malloc and the other
> associated functions?  Was this just a development/debug decision or
> something you feel is useful for the released code as well?

Just flexibility, I was trying to work out which allocations might be
freed during file opening or playback. In the end it turned out that only
one place actually frees any memory until ov_clear is called, which is
fwdindex, and that's why I treated it separately.

I'm sure the patch could be simplified but I figured in this form, it's much
easier to go back and re-add instrumentation for further tweaking.

> Lastly, this is a slightly more general question on the codec.  There are a
> couple places where realloc is used in Tremor - this is definitely hard to
> implement with this sort of static memory allocation.  However, after
> running all these tests I have yet to find a case where realloc is actually
> called - it only appears a couple times in the code.  Can anyone say if this
> code is truly dead or is some fix to deal with realloc (most likely just
> allocating for the whole amount immediately) going to be necessary?

I noticed there were realloc functions defined (mainly for buffers IIRC) but
they were never called. fwdindex blocks are freed and re-used but I think
they can possibly be replaced with alloca().

One thing to keep in mind, the original version of my patch didn't align the
memory blocks returned and this causes it to fail on ARM. I changed it to
round up the allocations to the nearest 4 bytes and that fixed it.

I have since made an additional memory management change. I noticed that I
couldn't open files with less than about 6KB of stack, which seemed
excessive. I removed some of the calls to alloca() in codebook.c and
replaced them with a function which allocates memory off the top of the
static memory area and returns it later. This works because the largest
alloca() blocks occur before the "heap" blocks are fully allocated, so
there's still enough memory left in that block at the time. Doing so reduced
the stack demands, so let me reduce my system stack and free up more space
for audio buffering. Those changes are mixed up with a bunch of other
changes right now but I can probably make a patch if it would be useful.

Nicholas