home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / sys / hp / 10226 < prev    next >
Encoding:
Internet Message Format  |  1992-09-09  |  3.0 KB
  1. Path: sparky!uunet!gatech!rutgers!modus!gear!cadlab!martelli
  2. From: martelli@cadlab.sublink.org (Alex Martelli)
  3. Newsgroups: comp.sys.hp
  4. Subject: Re: that HPUX cc compiler
  5. Message-ID: <1992Sep09.093710.3411@cadlab.sublink.org>
  6. Date: 9 Sep 92 09:37:10 GMT
  7. References: <1992Aug31.104950.1108@bohra.cpg.oz.au> <4722@prcrs.prc.com> <3939@sicsun.epfl.ch> <pejsjp4@fido.asd.sgi.com>
  8. Organization: CAD.LAB S.p.A., Bologna, Italia
  9. Lines: 56
  10.  
  11. shankar@sgi.com (Shankar Unni) writes:
  12. ...[on why passing a struct "works" as well as passing its address]...
  13. :No, it's not - it's doing a perfectly reasonable thing.
  14.  
  15. I fully agree on this.
  16.  
  17. :You are passing a struct by value to a function whose prototype is not
  18. :declared (I'm talking K&R compiles here for the moment). Since that's
  19. :a perfectly legal thing to do, the compiler does so. It just happens
  20. :that the way the HP compiler does it is to pass in the address of the
  21. :structure to the callee, *which is supposed to make a local copy
  22. :immediately* (automatically, that is, if the parameter is declared
  23. :correctly as a struct by value).
  24.  
  25. I think this is a very good choice of calling conventions.
  26.  
  27. :In this case, I agree that it may have been wiser to make the copy at
  28. :the point of call rather than at the point of entry - that way, the
  29. :above program would not have worked either optimized or unoptimized,
  30. :and the user would have been alerted.
  31.  
  32. I disagree with you on this.  Many times the called function will not
  33. need to change the struct argument it was passed; in this case an
  34. otherwise futile memory-to-memory copy is avoided by HP's calling
  35. conventions, if the compiler is able to get enough alias info when
  36. doing the called routine to omit the copy.  Even when it can't...:
  37.  
  38.     struct whatever { int first, second, third, fourth; }
  39.  
  40.     int calledrout(struct whatever it, int *tricky) {
  41.     (&tricky)++;
  42.     return it.first+it.third;
  43.     }
  44.  
  45. ...it may be able to reorder, or snatch needed fields from the structure
  46. BEFORE the possible side effects due to aliasing.  Even if the
  47. compiler can't do these optimizations today, by choosing this calling
  48. convention it seems to me that HP has kept the door open to the chance
  49. of introducing them painlessly in the future, i.e. without breaking
  50. compatibility between code made by the old compiler and code made by
  51. the old one.
  52.  
  53. Computers already spend too much time just copying reams of data from
  54. here to there "just in case"...:-), that I believe a calling convention
  55. designed to help with this should be praised, even if it does make it
  56. harder to catch a nasty user's bug!  After all as you say yourself the
  57. use of function prototypes would have squashed this bug right now!
  58.  
  59. :Still, all these are just ordinary implementation decisions, and just
  60. :happen to have odd consequences if you break the rules in a way that
  61. :the compiler can't detect.
  62.  
  63. Again, on this we fully agree.
  64. -- 
  65. Email: martelli@cadlab.sublink.org                   Phone: ++39 (51) 6130360
  66. CAD.LAB s.p.a., v. Ronzani 7/29, Casalecchio, Italia   Fax: ++39 (51) 6130294 
  67.