home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / dsp / 2523 < prev    next >
Encoding:
Internet Message Format  |  1992-11-04  |  2.5 KB
  1. Path: sparky!uunet!munnari.oz.au!metro!sequoia!ee.uts.EDU.AU!johnr
  2. From: johnr@ee.uts.edu.au (John Reekie)
  3. Newsgroups: comp.dsp
  4. Subject: Re: Philosophy of DO loops (Was: 96002 Question)
  5. Date: 5 Nov 92 07:09:03 GMT
  6. Organization: University of Technology, Sydney
  7. Lines: 46
  8. Message-ID: <johnr.720947343@ee.uts.EDU.AU>
  9. References: <1992Oct20.182501.12843@zip.eecs.umich.edu>> <HARDS4.92Oct22001752@evans.ee.adfa.oz.au> <johnr.719787436@ee.uts.EDU.AU> <1992Oct24.182055.14991@nuchat.sccsi.com>
  10. NNTP-Posting-Host: rossi.ee.uts.edu.au
  11.  
  12. steve@nuchat.sccsi.com (Steve Nuchia) writes:
  13.  
  14. >In article <johnr.719787436@ee.uts.EDU.AU> johnr@ee.uts.edu.au (John Reekie) writes:
  15. >>I think it's partly a problem with the language. For example,
  16. >>C has no way of representing modulo addressing. If I have
  17. >>a circular buffer amd I want to write one sample into it, then I
  18. >>can either i) do it in C and manually test and wrap the pointer,
  19. >>or ii) call an assmebler function and have it do teh write
  20. >>real efficiently --- apart from the call, that is! If the
  21.  
  22. >I have been working with the GNU C compiler on a 486 host.  I have
  23. >found that the _asm_ directive support in that compiler, combined
  24. >with the inline function directive, provide very good access to
  25. >special architectural features without having to step outside the
  26. >C language too far and without subroutine linkage overhead.
  27.  
  28. [Further explanation deleted.]
  29.  
  30. >In summary, I think there is a middle ground left out of the
  31. >conclusion quoted above.  It is possible, at least with GCC,
  32. >to efficiently and safely invoke specialized instruction sequences.
  33. >With some experince and good judgement it can even be reasonably
  34. >clean.
  35.  
  36. Yes, I agree that I hadn't considered (i.e. wasn't aware
  37. of!) the asm features of gcc, which makes my argument
  38. somewhat limp. 
  39.  
  40. What do you think about the idea of having the compiler
  41. "understand" certain objects, so it can generate efficient
  42. inline assembler code  for calls to those objects? If the
  43. compiler doesn't understand some object, then it would
  44. just compile the textual class definition. In say G++,
  45. could one define say a modulo buffer class, and then define
  46. a particular version of that class for a particular machine
  47. that will generate _inline_ assembler for calls to it?
  48. The idea is that your code is now portable -- the assembler
  49. templates are hidden inside the modulo buffer class, and if
  50. you port to a new device, you can either use the standard
  51. class, or (when you need the speed) write assembler
  52. templates for the new device. Will this work?
  53.  
  54. Regards
  55.  
  56. John Reekie
  57.  
  58.