home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / compiler / 1253 < prev    next >
Encoding:
Internet Message Format  |  1992-07-23  |  3.3 KB
  1. Path: sparky!uunet!ogicse!uwm.edu!wupost!think.com!spdcc!iecc!compilers-sender
  2. From: Olivier.Ridoux@irisa.fr (Olivier Ridoux)
  3. Newsgroups: comp.compilers
  4. Subject: Re: Pros and cons of high-level intermediate languages
  5. Keywords: C, translator
  6. Message-ID: <92-07-074@comp.compilers>
  7. Date: 23 Jul 92 08:18:04 GMT
  8. Article-I.D.: comp.92-07-074
  9. References: <92-07-068@comp.compilers>
  10. Sender: compilers-sender@iecc.cambridge.ma.us
  11. Reply-To: Olivier.Ridoux@irisa.fr (Olivier Ridoux)
  12. Organization: Compilers Central
  13. Lines: 61
  14. Approved: compilers@iecc.cambridge.ma.us
  15.  
  16.  
  17. ssp@csl36h.csl.ncsu.edu (Santosh Pande) writes:
  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. My comment is based on using C as an IL for compiling LambdaProlog.
  24. However, the specifics of LambdaProlog do not matter here.
  25.  
  26. boehm@parc.xerox.com (Hans Boehm):
  27. > I know of three problems:
  28. > a) (the one I'd personally most like to see fixed) The treatment of source
  29. > languages that require garbage collection is tricky.  It appears that the
  30. > only way not to lose appreciably in performance (and this is a bit
  31. > controversial) is to use a conservative garbage collector.  
  32.  
  33. We use another way.  All the memory management has been packaged into an
  34. abstract memory.  What the generated C programs do is to use this memory.
  35.  
  36. > b) Languages such as Scheme that "require" tail recursion elimination are
  37. > problematic.  
  38.  
  39. Like Prolog, LambdaProlog has a procedural semantics.  Though we map
  40. LambdaProlog procedures (predicates) on C functions, we do not map
  41. LambdaProlog procedure calls on C function calls.  In other words, we do
  42. not map LambdaProlog stack on the C stack.  We use instead the abstract
  43. memory mentioned above.
  44.  
  45. My general idea is that when two concepts are only approximately
  46. equivalent it is asking for problems to try mapping one onto the other.
  47.  
  48. > c) It's hard to efficiently implement a
  49. > compilation strategy that allocates activation records in the heap.  Some
  50. > of the cleverer implementations of first-class-continuations are hard to
  51. > express in C code.
  52.  
  53. The abstract memory again does the job.  Our execution scheme is
  54. continuation based.  The continuations (there are four of them because of
  55. non-determinism and other things) are all first-class objects.
  56.  
  57. I like to add a fourth problem:
  58.  
  59. d) There is no first-class label data-type.  One can neither store and
  60. read labels, nor goto stored labels.  I know about switch-statements, but
  61. it usually breaks the structure of the generated code.  For this problem,
  62. PL/1 would be a far better IL.
  63.  
  64. An optimistic final note.  On one hand, the generated code seems to break
  65. the admitted dimensions of human programming: huge identifiers made of
  66. several layers of prefixes, tags or module names, huge expression (e.g. in
  67. our scheme the unification subprogram of every clause is made in a single
  68. conjunctive expression (&&)), etc.  On the other hand, it is hard knowing
  69. the limits of an actual C compiler.  However, we never met them.  In our
  70. experiments, we only met problems with cpp.
  71.  
  72. Olivier Ridoux
  73. (ridoux@irisa.fr)
  74. -- 
  75. Send compilers articles to compilers@iecc.cambridge.ma.us or
  76. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  77.