home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / compiler / 1261 < prev    next >
Encoding:
Internet Message Format  |  1992-07-25  |  4.3 KB
  1. Path: sparky!uunet!dtix!darwin.sura.net!wupost!uwm.edu!ogicse!das-news.harvard.edu!spdcc!iecc!compilers-sender
  2. From: tarvydas@tsctrl.guild.org (tarvydas)
  3. Newsgroups: comp.compilers
  4. Subject: Re: Pros and cons of high-level intermediate languages
  5. Keywords: translator, design, C
  6. Message-ID: <92-07-082@comp.compilers>
  7. Date: 23 Jul 92 18:19:04 GMT
  8. References: <92-07-064@comp.compilers>
  9. Sender: compilers-sender@iecc.cambridge.ma.us
  10. Reply-To: tarvydas@tsctrl.guild.org (tarvydas)
  11. Organization: Compilers Central
  12. Lines: 78
  13. Approved: compilers@iecc.cambridge.ma.us
  14.  
  15. >I am looking for examples in which using C as IL will lead to inefficiencies.
  16.  
  17. . Mapping a language which has garbage collection, onto C.  Registers
  18. which point to non-garbage are hard to track when some C compiler thinks
  19. that it's smarter than your compiler.
  20.  
  21. . Mapping a language which has exception handling, onto C.  You could
  22. probably do better than setjmp/longjmp in specific cases.
  23.  
  24. . Mapping an object oriented language onto C.  The C model of
  25. compilation, producing an object file for later linking, is DEAD WRONG for
  26. OOP (*).
  27.  
  28. . Mapping an application language onto C, where it makes sense to
  29. globally allocate a register or two to hold very important,
  30. application-specific pointers to data/tables/etc.  C thinks that registers
  31. (other than the sp) can belong only to routines.
  32.  
  33. . Mapping a language which has scoping rules different from C onto C.
  34. You run into namespace problems (a la C++).
  35.  
  36. . Mapping a language which has strange control flows and optimizations
  37. onto C.  C's inane half-type-checking and declaration-before-use just get
  38. in the way - assembler is better (a sad statement, when C is nowadays
  39. acknowledged to be foremost an assembler :-).
  40.  
  41. . Mapping a language which actually cares about arithmetic overflow
  42. onto C.  Mapping a language with larger-than-C types onto C.  C lets ++
  43. leak out, but obliterates carry and overflow.
  44.  
  45.  
  46. > (2) I want to know whether any other language has been used as
  47. > extensively as C for IL
  48.  
  49. Most so-called portable compilers I've seen have used C as their IL (how
  50. do you think that my hate-list got to be as long as that above?  :-).
  51. I've observed that the vast majority of academics and practitioners in the
  52. world max out at no more than one innovation per project (sometimes, per
  53. lifetime :-).  This most often means that portability issues get relegated
  54. to the non-innovation levels.  No one ever got fired for using C or MSDOS
  55. (in this decade at least).
  56.  
  57. > (3) I want to learn about the efforts to evolve efficient ILs for
  58. > procedural languages
  59.  
  60. Automatic coder technology has become pretty good and has been backing
  61. into the idea of IL's.  See Fraser/Davidson "automated peepholer"
  62. technology (used in gcc) and Cordy Orthogonal Code Generator technology
  63. for ideas.  With Cordy's stuff, you get "IL's" which include high level
  64. constructs like loops, if-then-else, etc.
  65.  
  66. The biggest practical advantage of C as a portable IL is that it brings
  67. with it a mildly standard set of library routines.  Writing such routines
  68. for each target architecture is time consuming.  On the other hand, you
  69. don't have to emit C to be able to call these library routines. 
  70.  
  71. Paul Tarvydas
  72. TS Controls
  73. tarvydas@tsctrl.guild.org
  74.  
  75. (*) If you don't believe my statement that the .o model of compilation is
  76. wrong for OOP, observe how many .o files are deleted then totally
  77. recompiled when you make a simple change to a class in the middle of a
  78. hierarchy.  You can also see the defects of the C model of compilation
  79. oozing out in nefarious other ways - look at what they've done to Make
  80. nowadays (.KEEP_STATE and hidden conversations with the comiler passes),
  81. look at the goofy optimization Borland is pulling (precompiling .h files
  82. into something other than ASCII) - these are all symptoms of a technology
  83. having been pushed to the limit and beyond, without anyone stopping to
  84. think WHY.  [The best approximation to a better answer can be derived from
  85. first principles - imagine that the compiler is a closed environment, like
  86. that of Smalltalk.  Then, take out your Xacto knife and slit the data
  87. structures and dependencies so that you can write them onto persistent
  88. storage without losing any useful information.  You will not come up with
  89. a .o model.]
  90. -- 
  91. Send compilers articles to compilers@iecc.cambridge.ma.us or
  92. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  93.