[Tremor] TI55xx implementation: stuck

Tue Oct 19 22:48:34 PDT 2004

Hi Monty, 

Obviously you have a problem with TI DSPs and the corresponding tool
chain. I just want to state, that this is at least not the impression of
everyone in this mailing list. 
I worked with TI DSPs more than a year and it's even hard for me to
understand your arguments. A C5416 DSP has only a 16bit-Core (compared
to ARM 32bit) and this is the reason for the most inefficiencies. All
32-bit variables cannot be processed in registers (except the
accumulators) and all operations on 32bit variables were translated with
calls to stdlib functions. Furthermore the compiler itself does nothing
else than translating the c-code into assembler. The code is only
optimized, if the optimizer is enabled. I had a look on the efficiency
of the assembler output in a number of cases. If the optimizer is on (g2
or g3) and the Debug Info is disabled, in the most cases I couldn't get
a reasonable better result writing this part of code in assembler.
Exceptions are the calls to stdlib functions. Therefore it is best to
start optimization work in those parts which include a lot of
calculations - e.g. IMDCT, Overlap Add and Spectral Envelope - but I'm
convinced this is nothing new for you. 

I do not want to criticise you, especially not because I think you've
done really a great job by implementing Vorbis and Tremor. But I also
think that it is not fair to compare a 16bit-DSP with a
32bit-Microcontroller (which has even more an assembler instruction set
especially developed for efficient c-code translation). Let us compare
the C5416 DSP with 16-bit CPUs of other chip producers. I have not heard
from Ogg Vorbis running on another 16bit CPU. Is there any port
available?

I also had similar problems that CCS does not respond after running a
program. But after digging into the sources I always found the error on
my side. Once there was a stack overflow, once the memory allocated was
not available. (Then I wished that there would have been a check on
null-pointers after an alloc.) But finally the codec works fine, even on
a TI DSP (not C5416, but C5510)! Furthermore I think that CCS has
included a number of very nice and helpful features. When you use
DSP/BIOS you can display the current CPU-Load and tools are provided to
measure execution times of functions and modules. Additionally your
application is not limited to one task anymore - multitasking
applications are possible. 

Regards, Roland

-----Ursprüngliche Nachricht-----
Von: tremor-bounces at xiph.org [mailto:tremor-bounces at xiph.org] Im Auftrag
von Monty
Gesendet: Montag, 18. Oktober 2004 21:33
An: Jochen Wolff
Cc: tremor at xiph.org
Betreff: Re: [Tremor] TI55xx implementation: stuck

On Fri, Oct 15, 2004 at 06:57:18PM +0200, Jochen Wolff wrote:
> Hi all!
> 
> I'm trying to implement the Tremor code on a TI55xx DSP board. As I'm 
> a real newbe with both the Tremor Code and DSP programming I'm really 
> a bit stuck at the moment. And I'm not really good in all the 
> programming either. What I managed to do so far is compiling the 
> Tremor code with GCC and the provided makefile.
> 
> My main problems are:
> - Solving the problem with 64bit variables and rewriting the basic 
> math functions needed. Is it necessary to do that in assembler or can 
> I get away with it?

None of the 64 bit math needs to be fast; it's only used in a few places
to track 64 bit fields in the header, like granpos.

I have an implementation of the basic 64 bit math needed as a header,
I'll dig that out (nudge me if I don't send it in a day or two).

> - Spotting all commands in the code where 64bit variables cause a 
> problem.

ogg_uin64 should find them :-)

> - Transporting the code into TI CCStudio:

First off: I'm terribly sorry you're stuck with CCS.  CCS really drives
home that fact that TI doesn't seem to actually use any C code
themselves.  It is a perfectly awful compiler.  You can expect to need
to write alot of assembly to get acceptible performance.  The TI DSPs
are nice chips, but they do suffer from a low quality toolchain.

> understand what the autogen
> function does, replace it and get both the library and the program 
> code compiled in CCS.

All autogen does is try to automatically build a makefile that takes
into account all the quirks and requirements of a given platform, a
necessity under UNIX where you could be building on one of thousands of
OS/platform/toolchain variants.  However, the autogen stuff is useless
to you as you're on an embedded platform.  It's included in Tremor
mostly so that if you have a UNIX-like environment, you can build a copy
of Tremor for the general purpose CPU and use that other working copy as
a behavioral sanity check while porting.

> I've read in previous threads that some people have done it before. 
> However, the hints to the solutions of my problems were not sufficient

> for me.

I've ported Tremor to 5416.  I'm not in a mood to ever touch it again,
assuming I even could (After a code-merge from upstream and a recompile,
CCS got its panties wedged into a state where any attempt to touch the
Tremor object code causes the IDE to crash.  TI's support advice was to
'back out the changes that cause the UI to crash'. Thanks guys, but I'd
rather just abandon your product entirely. Fortunately other engineers
who were better with the 5416 took over the codebase at that time).

> Could
> someone please help me! Either by detailed information or maybe by 
> providing the modified source code? I would be extremely thankful!

I will get you some source code goodness.  I prefer you use it as a
guide and not take it as gospel; naturally, I'm good with Tremor but I
was never terribly good at working with the 5416.  For all I know, I'd
been going at it all wrong from the beginning.

Monty
_______________________________________________
Tremor mailing list
Tremor at xiph.org
 <http://lists.xiph.org/mailman/listinfo/tremor>
http://lists.xiph.org/mailman/listinfo/tremor

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.xiph.org/pipermail/tremor/attachments/20041020/82e808a2/attachment.html