home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / lang / c / 19390 < prev    next >
Encoding:
Internet Message Format  |  1993-01-07  |  2.4 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!usc!cs.utexas.edu!asuvax!ncar!noao!amethyst!organpipe.uug.arizona.edu!news
  2. From: dave@cs.arizona.edu (Dave Schaumann)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: compilers and code generation (struct vs. array)
  5. Message-ID: <1993Jan8.001225.16732@organpipe.uug.arizona.edu>
  6. Date: 8 Jan 93 00:12:25 GMT
  7. References: <1ihl0vINNof1@life.ai.mit.edu>
  8. Sender: news@organpipe.uug.arizona.edu
  9. Reply-To: dave@cs.arizona.edu (Dave Schaumann)
  10. Organization: University of Arizona
  11. Lines: 43
  12. In-Reply-To: sundar@billberry.ai.mit.edu (Sundar Narasimhan)
  13.  
  14. In article <1ihl0vINNof1@life.ai.mit.edu>, sundar@billberry (Sundar Narasimhan) writes:
  15. >Let's say a point is defined as
  16. >    struct point { 
  17. >        double x, y;
  18. >        }
  19. >or as
  20. >typedef double point[2];
  21. >
  22. >I'm interested in the usual operation on points. (i.e. 
  23. >additions, subtractions, multiplications, co-ordinate access,
  24. [...]
  25. >Do compilers usually generate the same code in both the above
  26. >cases?
  27.  
  28. It's dangerous to say anything about what "compilers usually generate";
  29. there's a large range of qualities of implementation out there.
  30.  
  31. That said, the short answer is "probably yes".
  32.  
  33. The long answer is that from a code generation point of view, a struct
  34. reference can be viewed as a base address plus a constant offset, and
  35. an array reference can be viewed as a base address plus a (potentially)
  36. variable offset.  In the case where you always use constant indexes in
  37. your arrays, it's a fairly easy optimization to generate the same code
  38. as would be generated for a struct offset.  Since C compilers are required
  39. to recognize constant expressions anyway, one would assume that most
  40. compilers would get this.
  41.  
  42. On the other hand, if it doesn't get this right, it's probably generating
  43. poor code elsewhere too, so that the difference between p.x and p[0] is
  44. probably going to be overwhelmed by other things anyway.
  45.  
  46. I'd say just go with what seems most natural.  This is probably good
  47. advice in any coding concern.  The big wins in optimization are far
  48. more in the area of designing basic algorithms than they are in the
  49. fine-tuning area of deciding between "p.x" and "p[0]".  If your program
  50. runs too slow, use a profiler.  Humans can do a pretty fair job when
  51. it comes to designing a complex system like a computer program, but
  52. when it comes to finding where it spends most of its processing time,
  53. we come in a (very) distant second to a simple automated accounting.
  54.  
  55. -- 
  56. Caught an internal error--.brainrc restored
  57.