home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / compiler / 2062 < prev    next >
Encoding:
Text File  |  1992-12-22  |  3.2 KB  |  69 lines
  1. Newsgroups: comp.compilers
  2. Path: sparky!uunet!world!iecc!compilers-sender
  3. From: vanpraet@imec.be
  4. Subject: compilers for DSP processors
  5. Reply-To: vanpraet@imec.be
  6. Organization: Compilers Central
  7. Date: Mon, 21 Dec 1992 11:18:33 GMT
  8. Approved: compilers@iecc.cambridge.ma.us
  9. Message-ID: <92-12-094@comp.compilers>
  10. Keywords: DSP, question
  11. Sender: compilers-sender@iecc.cambridge.ma.us
  12. Lines: 55
  13.  
  14. This article was already posted (in a different form) on comp.dsp but it
  15. only triggered a few interesting answers. Maybe comp.compilers can give
  16. additional input.
  17.  
  18. As far as I know most of the code for a DSP-processor is written in
  19. assembly language because either there is no suitable compiler available
  20. or the compiled code is not good enough. Code generated by a C-compiler
  21. for a commercial DSP-processor would be about 5 times as big as the same
  22. algorithm manually coded in assembler. This is a generalization that can
  23. offend some of you but I heard this from various sides, even from some DSP
  24. processor manufacturers. Although the manufacturers also said that it will
  25. be better in the future, as new DSP processors are designed with compilers
  26. for High Level Languages in mind.
  27.  
  28. - Do you agree on the above ? (the quality of DSP compilers)
  29. - What causes this factor of 5 on the code size ?
  30.    e.g. -> The instruction set of a DSP processor does not lend itself
  31.           to conventonal compiling techniques ?
  32.         -> the High Level Languages are not useful for DSP? 
  33.             - not enough parallelism in C (too difficult to extract the
  34.               parallelism)?
  35.             - too many possible constructs in C ? (a subset of C is better)
  36.             - non-procedural languages as e.g. Silage are better ?
  37.         -> no global ordering and scheduling of the generated code ?
  38.         -> no possibility of using all the provided tricks for the DSP
  39.            processors ?
  40.             - no or not enough use of the low-overhead-loop facility of a
  41.               processor as the "DO" for Motorola and the "RPT" for Texas
  42.               Instruments processors ?
  43.             - no use of special addressing ? (e.g. in circular buffers)
  44.             - no use of special block data moves ?
  45.             ...
  46.          ...
  47.  
  48. I also know of three code generation approaches that would generate more
  49. optimal code : - The GABRIEL (PTOLEMY) system of prof. Lee at Berkeley
  50.                  (mainly targeted towards the Motorola 56k)
  51.                - The code generator for Texas Instruments' TMS320C30 in the
  52.                  DSP-station of EDC (in Belgium)
  53.                - The SPW (Signal Processing Workstation) by Comdisco, Inc.
  54.  
  55. These don't start from a procedural language (resp. from block diagrams or
  56. from Silage) and have some sort of library of manually written
  57. code-pieces. They also perform some sort of global scheduling and
  58. optimization. Anyone used these ? What is their quality on real life
  59. examples ?
  60.  
  61. You can reply by email or post a follow-up (don't include this whole thing
  62. !).  If I get significant answers, a summary will be posted.
  63. --
  64. Johan Van Praet  | IMEC , Kapeldreef 75
  65. vanpraet@imec.be | 3001 HEVERLEE , BELGIUM
  66. -- 
  67. Send compilers articles to compilers@iecc.cambridge.ma.us or
  68. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  69.