home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / dsp / 2812 < prev    next >
Encoding:
Text File  |  1992-12-16  |  3.7 KB  |  79 lines
  1. Newsgroups: comp.dsp
  2. Path: sparky!uunet!mcsun!ub4b!imec.be!tiamat!vanpraet
  3. From: vanpraet@imec.be (Johan Van Praet)
  4. Subject: compilers for DSP processors
  5. Message-ID: <1992Dec16.141628.28304@imec.be>
  6. Followup-To: comp.dsp
  7. Lines: 65
  8. Sender: vanpraet@tiamat (Johan Van Praet)
  9. Nntp-Posting-Host: tiamat
  10. Reply-To: vanpraet@imec.be (Johan Van Praet)
  11. Organization: Imec 
  12. Date: Wed, 16 Dec 1992 14:16:28 GMT
  13.  
  14.  
  15. I am writing a report on different approaches to generate code for a
  16. DSP processor and would like to hear some opinions of the net-people
  17. about this.
  18.  
  19. As far as I know most of the code for a DSP-processor is written in
  20. assembler because either there is no suitable compiler available or
  21. the compiled code is not good enough. Code generated by a C-compiler
  22. for a commercial DSP-processor would be about 5 times as big as the
  23. same algorithm manually coded in assembler.
  24. On the other hand I read in an EDN issue (of 7 november 1991) that
  25. some people do 90% of their code in C and 10% of the code in assembly
  26. language (I think of this as an application of the 90/10 rule -- i.e.
  27. that 90% of the execution time of a program is spent in 10% of the
  28. code -- so that these 10% of code must be optimal).
  29.  
  30. - Which method do you use to write code ?
  31. - Do you agree on the above ? (on the use and the quality of DSP compilers)
  32. - What causes this factor of 5 on the code size ?
  33.    e.g. -> the input language ? 
  34.             - not enough parallelism in C (too difficult to extract the
  35.               parallelism)?
  36.             - too many possible constructs in C ? (a subset of C is better)
  37.             - non-procedural languages as e.g. Silage are better ?
  38.         -> no global ordering and scheduling of the generated code ?
  39.         -> no possibility of using all the provided tricks for the DSP
  40.            processors ?
  41.             - no or not enough use of the low-overhead-loop facility of a
  42.               processor as the "DO" for Motorola and the "RPT" for Texas
  43.               Instruments processors ?
  44.             - no use of special addressing ? (e.g. in circular buffers)
  45.             - no use of special block data moves ?
  46.             ...
  47.          ...
  48.  
  49. I also know of two code generation approaches that would generate more
  50. optimal code : - The GABRIEL (PTOLEMY) system of prof. Lee at Berkeley
  51.                  (mainly targeted towards the Motorola 56k)
  52.                - The code generator for Texas Instruments' TMS320C30 in the
  53.                  DSP-station of EDC (in Belgium)
  54.  
  55. These don't start from a procedural language (resp. from block
  56. diagrams and from Silage) and have both some sort of library of
  57. manually written code-pieces. They also perform some sort of global
  58. scheduling. 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
  62. thing !).  If I get significant answers, a summary will be posted.
  63.  
  64. +----------------------------+-----------------------------------+
  65. | Johan Van Praet            |           IMEC , Kapeldreef 75    |
  66. | vanpraet@imec.be           |           3001 HEVERLEE , BELGIUM |
  67. +----------------------------+-----------------------------------+
  68. |In theory, there is no difference between theory and practice.  |
  69. |But, in practice, there is.                                     |
  70. +----------------------------------------------------------------+
  71. --
  72. +----------------------------+-----------------------------------+
  73. | Johan Van Praet            |           IMEC , Kapeldreef 75    |
  74. | vanpraet@imec.be           |           3001 HEVERLEE , BELGIUM |
  75. +----------------------------+-----------------------------------+
  76. |In theory, there is no difference between theory and practice.  |
  77. |But, in practice, there is.                                     |
  78. +----------------------------------------------------------------+
  79.