home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / fortran / 3252 < prev    next >
Encoding:
Text File  |  1992-08-27  |  3.1 KB  |  81 lines
  1. Newsgroups: comp.lang.fortran
  2. Path: sparky!uunet!munnari.oz.au!cs.mu.OZ.AU!fjh
  3. From: fjh@cs.mu.OZ.AU (Fergus Henderson)
  4. Subject: Re: Small Language Wanted
  5. Message-ID: <9224117.23480@mulga.cs.mu.OZ.AU>
  6. Organization: Computer Science, University of Melbourne, Australia
  7. References: <DAVIS.92Aug23010605@pacific.mps.ohio-state.edu>     <H.3lvmyc56w&A@lionbbs.bs.open.de>     <1992Aug27.181926.5677@alchemy.chem.utoronto.ca>     <9224107.5975@mulga.cs.mu.OZ.AU>     <DAVIS.92Aug27211418@pacific.mps.ohio-state.edu> <DAVIS.92Aug28015332@pacific.mps.ohio-state.edu>
  8. Date: Fri, 28 Aug 1992 07:58:25 GMT
  9. Lines: 70
  10.  
  11. davis@pacific.mps.ohio-state.edu ("John E. Davis") writes:
  12.  
  13. [Example showing problems with K&R C not having prototypes]
  14.  
  15. >It has been pointed out to me by several people that this is compiler
  16. >dependent and the a true ansi compliant answer will produce the correct
  17. >answer. This is because instead of a declaration like:
  18. >
  19. >                   extern double pow(/* double, double */);
  20. >
  21. >the ANSI declaration would read:
  22. >
  23. >                   extern double pow(double, double);
  24. >
  25. >
  26. >This has the effect of performing the correct typecasts before calling the
  27. >function `pow'.
  28. >
  29. >But then this behavior contradicts something else the other poster said:
  30. >
  31. >     >pow(a,i)
  32. >
  33. >     >in your code, and "i" happens to be an integer then it can emit code to
  34. >     >        - call the standard pow() function after convertin
  35. >     >           i to a double
  36. >     >        - call a special function the calculates doubles to
  37. >     >          integer powers
  38. >     >        - calculate the exponentiation using inline code.
  39. >     >Ie. it can make EXACTLY the same optimizations that Fortran compilers
  40. >     >make when they see a**i.
  41. >     >[...]
  42. >     >Any function that is part of the standard library is a "built-in"
  43. >     >function. 
  44.  
  45. No, they are not contradictory.
  46. The compiler must generate code that has the *same effect* as
  47. simply converting to double and then calling pow(), but it is
  48. quite free to substitute any equivalent code which may be more
  49. efficient, for example by converting the call to a couple of inline
  50. multiplications.
  51.  
  52. >This seems to imply that if I do:
  53. >
  54. >int i = 4; float y, x = 2.0;  y = pow(x,i)
  55. >
  56. >The code for pow will recognize that 4.0 = (double) i is equivalent to the
  57. >integer 4 and will generate code like:
  58. >
  59. >       return(tmp = 2.0 * 2.0, tmp * tmp);
  60. >
  61. >as opposed something like 
  62. >
  63. >       return( exp ( 4.0 * log(2.0));
  64. >
  65. >Are there really any existing C compliers out there that perform such
  66. >optimizations?
  67.  
  68. Both GNU C and Microsoft C will inline some standard library functions,
  69. even in C (not C++) programs. This is generally used for simple functions
  70. like strcpy, memcpy, strcmp, etc.  I don't know of any compilers that
  71. apply strength reduction optimizations to calls to pow(), but it
  72. is certainly allowed by the standard and would not be difficult to
  73. implement.
  74.  
  75. -- 
  76. Fergus Henderson (fjh@munta.cs.mu.OZ.AU) .sig truncated to avoid bugs in system
  77. software that result in duplication of .sig apparently at random (AARRGGHHH!!!)
  78. -- 
  79. Fergus Henderson (fjh@munta.cs.mu.OZ.AU) .sig truncated to avoid bugs in system
  80. software that result in duplication of .sig apparently at random (AARRGGHHH!!!)
  81.