Xref: utzoo comp.compilers:1231 comp.dsp:880
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!mintaka!spdcc!esegue!compilers-sender
From: mhorne@ka7axd.wv.tek.com (Mike Horne)
Newsgroups: comp.compilers,comp.dsp
Subject: Re: Is there a compiler for TMS320C25 somewhere?
Keywords: C, question
Message-ID: <8596@orca.wv.tek.com>
Date: 5 Sep 90 22:27:07 GMT
References: <1990Sep4.092517.13387@isy.liu.se>
Sender: compilers-sender@esegue.segue.boston.ma.us
Reply-To: Mike Horne <mhorne@ka7axd.wv.tek.com>
Followup-To: comp.dsp
Organization: Visual Systems Group, Tektronix, Inc.
Lines: 23
Approved: compilers@esegue.segue.boston.ma.us

In a recent article by tommyp@isy.liu.se (Tommy Pedersen):
> 
> [People I know in the DSP biz tell me that although there are many C
> compilers for DSP chips, nobody uses them because they're all too slow.
> -John]

I'm assuming you mean poor code generation (i.e. slow code)...

Generally speaking, few people use compilers to generate code for DSP chips
for *time critical* code sections.  Note that this includes just about all
signal processing algorithms.  However, you can use a high-level language
(such as C) to build the *structure* of the program and use in-line assembly
for time critical sections.  I've found that this greatly enhances the
readability of the code and significantly reduces the maintenance requirements.
This `hybrid' approach is especially nice for variable passing and stack
management.

Mike
DSP Video I/O Architecture
Tektronix, Inc., Wilsonville, OR
-- 
Send compilers articles to compilers@esegue.segue.boston.ma.us
{ima | spdcc | world}!esegue.  Meta-mail to compilers-request@esegue.