Re: C code .vs. Assembly code for Microcontrollers/DSPs ?

Ron Nicholson <rhn@sgi.com>
6 Mar 1996 21:13:29 -0500

          From comp.compilers

Related articles
[5 earlier articles]
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? torbenm@diku.dk (1996-03-04)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? andrew@memex.co.uk (Andrew Cruickshank) (1996-03-04)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? fink@post.tau.ac.il (1996-03-05)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? torbenm@diku.dk (1996-03-05)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? hatrjo@hat-fi.kone.com (Risto Jokinen) (1996-03-05)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? max@gac.edu (1996-03-06)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? rhn@sgi.com (Ron Nicholson) (1996-03-06)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? yatesc@csee.usf.edu (1996-03-06)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? cdg@nullstone.com (1996-03-07)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? thinklab@earth.usa.net (1996-03-08)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? tchannon@black.demon.co.uk (Tim Channon) (1996-03-08)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? koopman@cs.cmu.edu (1996-03-08)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? hbaker@netcom.com (1996-03-08)
[38 later articles]
| List of all articles for this month |
From: Ron Nicholson <rhn@sgi.com>
Newsgroups: comp.compilers,comp.dsp
Date: 6 Mar 1996 21:13:29 -0500
Organization: Silicon Graphics, Inc.
References: 96-03-006 96-03-025 96-03-040
Keywords: optimize, DSP

"David J. Starr" <dstarr@pop-3.std.com> writes:
>... DSP's are a different breed of cat. The performance in a DSP
>is gained from the use of multiple address spaces, all fetched
>simultaniously. For good DSP performance, the programmer has to
>be able to specify which arrays of data go into which memories.


Torben AEgidius Mogensen wrote:
> This doesn't sound too difficult to solve in a compiler: whenever
> a MUL between array elements happen, a constraint that the arrays
> should be in different memories is generated.


Unfortunately, the dynamic characteristics of the algorithm is lost.
A compiler like this would optimize based on static analysis, which
may be exactly the wrong thing.


- HLL's help programmers write larger programs in a given time. DSP
programs tend to be short.


- HLL's tend to be limited to standard portable data types. Many
DSP's use non-standard data types and operators to enhance perfomance
and reduce code size.


- While it's possible to write a compiler that would produce any given
code sequence, it's much harder to verify that the compiler is still
correct than it is to verify that the code sequence works for it's one
specific intended application.


- DSP's tend to go in high volume non-reusable applications. The cost
per byte of ROM may be much larger than the cost per line of code.
---
Ron Nicholson mailto:rhn@sgi.com http://www.nicholson.com/rhn/
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.