home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / compiler / 1247 < prev    next >
Encoding:
Internet Message Format  |  1992-07-21  |  4.3 KB
  1. Path: sparky!uunet!cs.utexas.edu!wupost!sdd.hp.com!hp-cv!ogicse!das-news.harvard.edu!spdcc!iecc!compilers-sender
  2. From: boehm@parc.xerox.com (Hans Boehm)
  3. Newsgroups: comp.compilers
  4. Subject: Re: Pros and cons of high-level intermediate languages
  5. Keywords: translator, design
  6. Message-ID: <92-07-068@comp.compilers>
  7. Date: 21 Jul 92 16:18:45 GMT
  8. Article-I.D.: comp.92-07-068
  9. References: <92-07-064@comp.compilers>
  10. Sender: compilers-sender@iecc.cambridge.ma.us
  11. Reply-To: boehm@parc.xerox.com (Hans Boehm)
  12. Organization: Xerox PARC
  13. Lines: 84
  14. Approved: compilers@iecc.cambridge.ma.us
  15.  
  16. ssp@csl36h.csl.ncsu.edu (Santosh Pande) writes:
  17.  
  18. >    I am interested in knowing the pros and cons of using an
  19. >intermediate language (IL) in general. In particular I find 'C' has been
  20. >used extensively as the IL in many situations: Modula, SISAL, AT&T Cfront
  21. >for C++ etc.
  22.  
  23. Other languages for which compilers that target C exist are: Common Lisp,
  24. Fortran, Scheme, ML, Sather, Eiffel, CLU, Mesa, Russell, ...
  25.  
  26. >    Some of the reasons I can see in favor of such an approach are:
  27. >  ...
  28.  
  29. >    However, such an approach might also suffer from:
  30. >  ...    
  31. >    (2) Efficiency is dictated to a large degree by the target C
  32. >Compiler,
  33.  
  34. This can often be a major advantage of using C as an IL.  The manufacturer
  35. usually supplies a decent C compiler, which was written with full
  36. knowledge of machine pipeline constraints, etc.  These are often not fully
  37. available to somebody else.
  38.  
  39. >    (3) Translation in some situations might involve clumsy data
  40. >structures and thus loss of efficiency.
  41.  
  42. >    The second reason is especially important because the many C
  43. >Compilers seem to suffer from the tough problems of aliases and side
  44. >effects in interprocedural analysis (except in some cases). 
  45.  
  46. Note that this matters only for those optimizations that can't easily be
  47. expressed at the C source level.  Most of the above compilers, especially
  48. for languages like Scheme, try to perform a reasonable number of higher
  49. level optimizations before they generate the C code.
  50.  
  51. >    Now my questions:
  52. >    (1) I am looking for examples in which using C as IL will lead to
  53. >inefficiencies,
  54.  
  55. I know of three problems:
  56. a) (the one I'd personally most like to see fixed) The treatment of source
  57. languages that require garbage collection is tricky.  It appears that the
  58. only way not to lose appreciably in performance (and this is a bit
  59. controversial) is to use a conservative garbage collector.  But the C
  60. standard does not guarantee that C compiler optimizations are safe in the
  61. presence of such a collector.  Probably most such current implementations
  62. don't fully address this problem, and use a conservative collector anyway,
  63. and get away with it.  (David Chase and I have some ideas on fixing this
  64. with almost no cooperation from the C compiler.  Details available on
  65. request.)
  66.  
  67. b) Languages such as Scheme that "require" tail recursion elimination are
  68. problematic.  It's hard to perform that optimization at the C source level
  69. without losing performance, or generating huge monolithic functions that
  70. tend to exceed C compiler limits.  c) It's hard to efficiently implement a
  71. compilation strategy that allocates activation records in the heap.  Some
  72. of the cleverer implementations of first-class-continuations are hard to
  73. express in C code.
  74.  
  75. My impression is that for vaguely Pascal-like languages (e.g. Mesa),
  76. compiling through C generally loses very little performance, and may in
  77. fact win, if it's done sufficiently carefully.  For Scheme or ML-like
  78. languages, life is a little harder.  You either lose some performance, or
  79. you have to make some other compromises.
  80.  
  81. >    (2) I want to know whether any other language has been used as
  82. >extensively as C for IL,
  83. >    (3) I want to learn about the efforts to evolve efficient ILs 
  84. >(just like IFs) for procedural languages.
  85.  
  86. >[In answer to question 2, I expect that there are a lot more langauges
  87. >that use Fortran as intermediate code than ones that use C.  Fortran has
  88. >been around longer and lets you do lots of gross low level hacks that you
  89. >always seem to want in intermediate code. -John]
  90.  
  91. This hasn't been true recently, I think.  I can only come up with one or
  92. two uses of Fortran as an intermediate language, and that is for rather
  93. special purpose source languages.
  94.  
  95. Hans-J. Boehm
  96. (boehm@parc.xerox.com)
  97. -- 
  98. Send compilers articles to compilers@iecc.cambridge.ma.us or
  99. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  100.