home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / dsp / 2888 < prev    next >
Encoding:
Text File  |  1992-12-31  |  1.9 KB  |  40 lines
  1. Newsgroups: comp.dsp
  2. Path: sparky!uunet!think.com!enterpoop.mit.edu!world!moshier
  3. From: moshier@world.std.com (Stephen L Moshier)
  4. Subject: Re: Motorola's gcc diffs?
  5. Message-ID: <C05AvJ.KKD@world.std.com>
  6. Organization: The World Public Access UNIX, Brookline, MA
  7. References: <Bzs3CD.26o@world.std.com> <1992Dec25.181709.19960@qcj.icon.com>     <BzvJAM.H8C@world.std.com> <JEFF.92Dec31092357@dsp.sps.mot.com>
  8. Date: Thu, 31 Dec 1992 22:38:07 GMT
  9. Lines: 29
  10.  
  11.  
  12.    Whether Motorola should feel proud of their compiler is a question
  13. that is different from What is this stuff on a computer in Finland.
  14. My answer to the former is No, but I do hope you'll keep trying.
  15.  
  16.    I paid $700 cash for the original attempt.  Before deciding whether
  17. to upgrade, I asked Motorola some questions. No, it does not do pipeline
  18. optimization.  No, data in x, y, p memory spaces are not supported; you
  19. have to choose either x or y and not both.  No, it does not have a
  20. fractional data type (can that really be true?).  Well, I decided to
  21. hold off and stick with the one I made from Dave Dunfield's 8086 C
  22. compiler.
  23.  
  24.    Motorola has won every design-in I've done since the chip was
  25. announced, except when the decision was based on price rather than
  26. technical merit.  A DSP56000 can do three things in one instruction. 
  27. But if the compiled code takes ten instructions to do one thing, what
  28. good is that?  I didn't buy a DSP chip to go slow.  I won't buy
  29. software that makes it go slow.
  30.  
  31.    Perhaps TI is the only DSP company that can *afford* a real compiler
  32. project.  TI, with its near-monopoly market share, has improved its
  33. software from awful in 1982 to very good in 1992.  (But I can't use
  34. their chip any more! It always seems to work out slower than the
  35. alternatives.) Meanwhile the other companies presumably do what software
  36. support they can, but they sure leave a lot to wish for.  I say, Never
  37. mind the windows and COFF and source level debuggers, just give us a
  38. better compiler.
  39.  
  40.