NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/dsp/2897

Text File | 1993-01-01 | 3.4 KB | 74 lines

Newsgroups: comp.dsp
Path: sparky!uunet!zaphod.mps.ohio-state.edu!cs.utexas.edu!oakhill!oakhill!jeff
From: [e-mail] (Jeff Enderwick)
Subject: Re: Motorola's gcc diffs?
In-Reply-To: [e-mail]'s message of 31 Dec 92 22:38:07 GMT
Message-ID: <[e-mail]>
Sender: [e-mail]
Nntp-Posting-Host: 223.10.249.92
Organization: Motorola DSP Compilers
References: <[e-mail]> <[e-mail]>
    <[e-mail]> <[e-mail]>
    <[e-mail]>
Date: 1 Jan 93 17:26:38
Lines: 58


>   I paid $700 cash for the original attempt.  Before deciding whether
>to upgrade, I asked Motorola some questions. No, it does not do pipeline
>optimization.  No, data in x, y, p memory spaces are not supported; you
>have to choose either x or y and not both.  No, it does not have a
>fractional data type (can that really be true?).  Well, I decided to
>hold off and stick with the one I made from Dave Dunfield's 8086 C
>compiler.

Kind of. Actually we do attempt to jam multiple instructions into
single words, and we also try to avoid pipeline hazards. If you're
speaking of "software pipelining", we haven't implemented the aliasing
analysis that is needed to do it right. The X / Y memory issue is a
very tricky one.  Given a pointer as an argument, you need to be able
to figure out which data space it belongs to; this implies modifying C
(the language).  Basically, what you get is GCC with some extra
optimizations thrown in.

>   Perhaps TI is the only DSP company that can *afford* a real compiler
>project.  TI, with its near-monopoly market share, has improved its
>software from awful in 1982 to very good in 1992.  (But I can't use
>their chip any more! It always seems to work out slower than the
>alternatives.) Meanwhile the other companies presumably do what software
>support they can, but they sure leave a lot to wish for.  I say, Never
>mind the windows and COFF and source level debuggers, just give us a
>better compiler.

I used to think like you. Personally, I find implementing compiler
optimizations to be the fun part of my job. I wish everyone had your
perspective. Unfortunately for us, most customers don't. If a compiler
is even 10% slower than hand code for time critical loops, then the
DSP engineer is going to hand code them. Maybe you work on projects
where volume is low, and the cost of parts doesn't matter, yielding a
situation where you'd rather spend a little more on a faster part that
take the time to hand code. Most customers who will do high volume
production will want to use the slowest (cheapest) part that will get
the job done. On some loops you may hit paydirt with a compiler; on
most you're compiled code will be slower that hand code.

Overwhelmingly, DSP compiler customers seem to use C to speed the
development of the non-time critical sections of their application.
The sections that are tight for time are hand coded. The goal of
introducing better optimizers is to move the frontier where the
engineer needs to hand code. As for debuggers and windows these are a
really big deal. people want to be able to debug systems as easily and
as quickly as possible. Good debuggers are a high priority for most
customers.

I'd be really interested in finding out which TI compiler you're talking
about (and which version). I'd like to get a copy and look at what comes
out!

    thanks,

    Jeff Enderwick
    [e-mail]