home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / compiler / 1248 < prev    next >
Encoding:
Internet Message Format  |  1992-07-22  |  4.5 KB
  1. Path: sparky!uunet!usc!sdd.hp.com!hp-cv!ogicse!das-news.harvard.edu!spdcc!iecc!compilers-sender
  2. From: chased@rbbb.Eng.Sun.COM (David Chase)
  3. Newsgroups: comp.compilers
  4. Subject: Re: Pros and cons of high-level intermediate languages
  5. Keywords: translator, design
  6. Message-ID: <92-07-069@comp.compilers>
  7. Date: 21 Jul 92 18:01:44 GMT
  8. Article-I.D.: comp.92-07-069
  9. References: <92-07-064@comp.compilers>
  10. Sender: compilers-sender@iecc.cambridge.ma.us
  11. Reply-To: chased@rbbb.Eng.Sun.COM (David Chase)
  12. Organization: Sun Microsystems, Mt. View, Ca.
  13. Lines: 89
  14. Approved: compilers@iecc.cambridge.ma.us
  15.  
  16. ssp@csl36h.csl.ncsu.edu (Santosh Pande) writes:
  17. >    I am interested in knowing the pros and cons of using an
  18. >intermediate language (IL) in general. In particular I find 'C' has been
  19. >used extensively as the IL in many situations: Modula, SISAL, AT&T Cfront
  20. >for C++ etc.
  21.  
  22. >    Some of the reasons I can see in favor of such an approach are:
  23. >    (1) Ease of portability (a feature of C that made it so popular!),
  24.  
  25. yes.
  26.  
  27. >    (2) Easy retargettability (one can patch the run-time support with a
  28. >customized library for the given target architecture easily), and,
  29.  
  30. yes.
  31.  
  32. >    (3) Relative ease of mapping a given intermediate form (IF) to C's
  33. >data structures. 
  34.  
  35. so-so.  The closer the original language is to C, the better.  As soon as
  36. you have a non-C concept (e.g, continuations, or guaranteed tail-call, or
  37. garbage collection, or threads) things begin to get a bit rougher.  Note
  38. that there are existence proofs demonstrating that these things can be
  39. done, but the non-C concepts are a lot harder to translate.
  40.  
  41. Note well that my experience (Modula-3) and the experience of friends who
  42. have done similar things indicates that you should dive to a fairly low
  43. level in the generated C.  In particular, you should consider generating
  44. "cast-ful" code, unless you have an extremely good command of exactly what
  45. happens when you combine types of various flavors in arithmetic.
  46.  
  47. >    However, such an approach might also suffer from:
  48. >    (1) Debugging is hellish,
  49.  
  50. It's not as bad as you might think (for the compiler-writer, that is).
  51. This depends largely on you, and largely on the language that you are
  52. compiling -- for Modula-3, since all pointer types were tagged, we were
  53. able to generate P_<typename> subroutines that did an excellent job of
  54. formatting data structures.  We tinkered with insertion of #line
  55. directives (back to the M3 source), and sometimes it succeeded
  56. wonderfully, but too often it would be subtly misleading at just the wrong
  57. time.  I tried to not mangle variable names excessively, and that helped.
  58.  
  59. >    (2) Efficiency is dictated to a large degree by the target C
  60. >Compiler,
  61.  
  62. Yes and no.  This depends lots on the code that you generate.  I took the
  63. approach (for Olivetti M3) that we couldn't rely on the optimizer because
  64. we were using garbage collection and exception handling (implemented with
  65. setjmp and longjmp), and so I took great care in the code that I
  66. generated.
  67.  
  68. >    (3) Translation in some situations might involve clumsy data
  69. >structures and thus loss of efficiency.
  70.  
  71. It's not clear what you mean here.  Compile-time efficiency? (it sucks,
  72. generally) Run-time efficiency?  (it depends.)
  73.  
  74. >    Now my questions:
  75. >    (1) I am looking for examples in which using C as IL will lead to
  76. >inefficiencies,
  77.  
  78. Aliasing analysis.  You already know about Fortran.  Other places where
  79. this can happen include reference to pieces of descriptors that you "know"
  80. won't change because they are part of your run-time.  You can get around
  81. this by pre-loading everything that won't change into a local variable,
  82. but this could lead to a Big Surprise for the target C compiler.  ("Big
  83. Surprise" means potentially slow compilation and/or slow execution, or
  84. (worse) overflowed internal tables.)
  85.  
  86. Also, the lack of (portable) register globals, or (portable) lightweight
  87. access to thread-local storage can screw you up.  If you want to write a
  88. compacting garbage collector, the intermediate C compiler introduces
  89. uncertainty as to just where the pointers are stored in the activation
  90. records, and what has been done to them.  There are other clever tricks
  91. that you might want to try (special code generation for critical sections,
  92. special code generation for exception handling) that are completely
  93. off-limits if you use C as an IL.
  94.  
  95. >    (3) I want to learn about the efforts to evolve efficient ILs 
  96. >(just like IFs) for procedural languages.
  97.  
  98. What's the difference between an IL and an IF?
  99.  
  100. David Chase
  101. Sun
  102. -- 
  103. Send compilers articles to compilers@iecc.cambridge.ma.us or
  104. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  105.