home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / compiler / 1268 < prev    next >
Encoding:
Text File  |  1992-07-29  |  2.9 KB  |  74 lines

  1. Newsgroups: comp.compilers
  2. Path: sparky!uunet!gatech!destroyer!sol.ctr.columbia.edu!eff!world!iecc!compilers-sender
  3. From: graham@maths.su.oz.au (Graham Matthews)
  4. Subject: Re: Pros and cons of high-level intermediate languages
  5. Reply-To: graham@maths.su.oz.au (Graham Matthews)
  6. Organization: Sydney University Computing Service, Sydney, NSW, Australia
  7. Date: Sat, 25 Jul 1992 01:57:13 GMT
  8. Approved: compilers@iecc.cambridge.ma.us
  9. Message-ID: <92-07-089@comp.compilers>
  10. References: <92-07-064@comp.compilers> <92-07-068@comp.compilers>
  11. Keywords: translator, design
  12. Sender: compilers-sender@iecc.cambridge.ma.us
  13. Lines: 59
  14.  
  15. (Santosh Pande) writes:
  16. >I am interested in knowing the pros and cons of using an
  17. >intermediate language (IL) in general. In particular I find 'C' has 
  18. >been used extensively as the IL in ..
  19. >..
  20. >    (1) I am looking for examples in which using C as IL will lead to
  21. >inefficiencies,
  22.  
  23. (Hans Boehm) writes:
  24. >a) (the one I'd personally most like to see fixed) The treatment of 
  25. >source languages that require garbage collection is tricky.  It 
  26. >appears that the only way not to lose appreciably in performance 
  27. >(and this is a bit controversial) is to use a conservative garbage 
  28. >collector.  But the C standard does not guarantee that C compiler 
  29. >optimizations are safe in the presence of such a collector. 
  30.  
  31. I am not sure I understand what you are talking about here Hans.  As far
  32. as I can see if the C code you produce is not safe in the presence of
  33. garbage collection then you are generating incorrect C code. There is
  34. nothing in C that makes it "garbage collection unsafe" even with a
  35. non-conservative garbage collection.
  36.  
  37. For example say you have something of the form
  38.  
  39.     access_to_memory = function_that_causes_garbage_collection
  40.  
  41. Now if you compile this directly into C you are in trouble as C
  42. does not define the order of evaluation of the lhs with respect
  43. to the rhs (if the rhs is done first you are ok otherwise you
  44. have problems).
  45.  
  46. However this problem can be handled by compiling into C code of
  47. the form,
  48.  
  49.     temp = function_that_causes_garbage_collection;
  50.     access_to_memory = temp;
  51.  
  52. This construction forces the order of evaluation you require.  If an
  53. optimizer "optimises" this code back to the original form then your
  54. optimiser is incorrect.
  55.  
  56. So as far as I can see C is not unsafe in the presence of garbage
  57. collection as long as you are careful in your code emission. Your code
  58. will not be as fast as native C but then as far as I can see there is no
  59. way to avoid forcing the order of evaluation in any general solution to
  60. the above probelm so C will do no worse than any other system.
  61.  
  62. Perhaps you have some specific problems in mind ...
  63.  
  64. graham
  65. --
  66. Graham Matthews
  67. Pure Math, Uni.Sydney, Oz
  68. graham@maths.su.oz.au
  69. [The usual problem is to identify all possible live data, notably that
  70. pointed to by variables on the stack and in registers. -John]
  71. -- 
  72. Send compilers articles to compilers@iecc.cambridge.ma.us or
  73. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  74.