Vorbis dev - Mar 2002 - alloca() problem with CodeWarrior

Thanks for the http://vorbis.com link. That worked. But I looked in the
download area and there is no SDK for Mac OS 9. So I am compiling the vorbis
code directly into my app.

The problem I am having now is that the CodeWarrior 5.0 compiler has a bug
with alloca(). It allocates the area on the stack but, under some
circumstances, it does not restore the stack pointer at the end of the
routine. You can imagine what happens next. This happens in
vorbis_lpc_predict(). I have tried different optimization levels, and tried
making arbitrary changes to the code to see if the compiler could be tricked
into compiling correct code but to no avail.

Question: does anyone have precompiled static libogg, libvorbis and
libvorbisenc for Mac OS 9 available?

My other alternative is to purchase a $700 upgrade to CodeWarrior
7.0.....Gulp.

By the way, if you are doing cross-platform audio, you might like PortAudio.
It's a free open-source cross-platform audio API. Visit
"http://www.portaudio.com/".

Phil Burk

<p><p><p><p>--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to
'vorbis-dev-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

> The problem I am having now is that the CodeWarrior 5.0 compiler has a bug
> with alloca(). It allocates the area on the stack but, under some
> circumstances, it does not restore the stack pointer at the end of the
> routine. You can imagine what happens next. This happens in
> vorbis_lpc_predict(). I have tried different optimization levels,
> and tried
> making arbitrary changes to the code to see if the compiler could
> be tricked
> into compiling correct code but to no avail.
If you're really stuck, you could use the heap, but the sucky part is you
have to track down all the alloca's and make sure you have frees in the exit
code, may not be very fun to do as there are alloca's scattered all over
vorbis.

Later,
Alan

<p><p><p><p><p><p><p>--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to
'vorbis-dev-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

Phil Burk wrote:
>The problem I am having now is that the CodeWarrior 5.0 compiler has a bug
>with alloca(). 
>
Did you apply the CW 5.3 patch? It should be freely downloadable from 
www.metrowerks.com. I don't know if it fixes this bug, but I use it for 
all my work. (I don't tend to use alloca().)

Ben.

<p>--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to
'vorbis-dev-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

> The problem I am having now is that the CodeWarrior 5.0 compiler has a bug
> with alloca(). It allocates the area on the stack but, under some
> circumstances, it does not restore the stack pointer at the end of the
> routine. You can imagine what happens next. This happens in
> vorbis_lpc_predict().
That routine is never executed.

<p>Segher

<p>--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to
'vorbis-dev-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

THANK YOU Ben!
I applied the 5.3 patch for CodeWarrior 5.0 on Mac OS 9 and it fixed the
problem with alloca() corrupting the stack pointer.

The alloca() function is used throughout the Vorbis code base. In my Google
searches, I saw many cases where alloca() caused problems on many machines.
It is often implemented incorrectly by compilers. Plus it requires lots of
stack space. There was a discussion a while back about removing alloca()
calls from Ogg Vorbis. I would like to add one vote for that mod.

    http://www.google.com/search?q=alloca+crash

Phil Burk
>>The problem I am having now is that the CodeWarrior 5.0 compiler has a
bug
>>with alloca().
>>
Ben Stanley wrote:
>Did you apply the CW 5.3 patch? It should be freely downloadable from
>www.metrowerks.com. I don't know if it fixes this bug, but I use it for
>all my work. (I don't tend to use alloca().)
<p><p>--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to
'vorbis-dev-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

Heh, segher, of all the people on this list, you should be one of the
last to say such a thing. ;)
> -----Original Message-----
> From: owner-vorbis-dev@xiph.org [mailto:owner-vorbis-dev@xiph.org]On
> Behalf Of Segher Boessenkool
> Sent: Friday, March 15, 2002 1:51 PM
> To: vorbis-dev@xiph.org
> Subject: Re: [vorbis-dev] alloca() problem with CodeWarrior
> 
> 
> 
> 
> Brian Hook wrote:
> > 
> > I think Phil brings up some real good points about embedded 
> systems --
> > given the nature of Ogg Vorbis, ease of porting to embedded systems
> > seems a worthy goal.
> 
> Most embedded systems use gcc.  gcc has alloca().
> 
> Most embedded systems won't use libvorbis _anyway_, due to performance
> problems.
> 
> 
> Segher
> 
> 
> --- >8 ----
> List archives:  http://www.xiph.org/archives/
> Ogg project homepage: http://www.xiph.org/ogg/
> To unsubscribe from this list, send a message to 
> 'vorbis-dev-request@xiph.org'
> containing only the word 'unsubscribe' in the body.  No 
> subject is needed.
> Unsubscribe messages sent to the list will be ignored/filtered.
> 
--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to
'vorbis-dev-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

>> Anyone ever port libvorbis to a GameBoy Advance?
> It has an ARM cpu.  ARM integer Vorbis decoder implementations exist.
I'm not up to speed on GBA but I thought I saw a couple of years back the
CPU specs and it doesn't look like a very powerful beast. It's not even
nearly as powerful as the PS1/Saturn generation and Vorbis would be a challenge
on those. I think the ARM core runs no faster than 16 Mhz, not sure of the exact
number though. I recalled hearing that the GBA would need almost all it's
power just to play a 16-bit stereo PCM sample. So I'd think Vorbis on GBA
would be a pretty tough achievement.

<p>--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to
'vorbis-dev-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

>> I think Phil brings up some real good points about embedded systems --
>> given the nature of Ogg Vorbis, ease of porting to embedded systems
>> seems a worthy goal.
>
>Most embedded systems use gcc.  gcc has alloca().
One thing that has been missed in all this is that many systems limit stack.

BeOS (not embedded, but an example I'm familiar with) can't encode
in more than 32k chunks of PCM data. The amount of stack Elate
uses is dictated at compile time, the standard is 16k.

It would be handy to get rid of alloca in total IMHO.

Dave

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to
'vorbis-dev-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.