Re: Pros and cons of high-level intermediate languages

acha@CS.CMU.EDU (Anurag Acharya)
Fri, 24 Jul 1992 15:28:33 GMT

          From comp.compilers

Related articles
[5 earlier articles]
Re: Pros and cons of high-level intermediate languages Olivier.Ridoux@irisa.fr (1992-07-23)
Re: Pros and cons of high-level intermediate languages fjh@munta.cs.mu.OZ.AU (1992-07-23)
Re: Pros and cons of high-level intermediate languages tmb@idiap.ch (1992-07-23)
Re: Pros and cons of high-level intermediate languages henry@zoo.toronto.edu (1992-07-23)
Re: Pros and cons of high-level intermediate languages tarvydas@tsctrl.guild.org (1992-07-23)
Re: Pros and cons of high-level intermediate languages graham@maths.su.oz.au (1992-07-24)
Re: Pros and cons of high-level intermediate languages acha@CS.CMU.EDU (1992-07-24)
Re: Pros and cons of high-level intermediate languages graham@maths.su.oz.au (1992-07-25)
Re: Pros and cons of high-level intermediate languages fjh@munta.cs.mu.OZ.AU (1992-07-25)
Re: Pros and cons of high-level intermediate languages moss@cs.umass.edu (1992-07-25)
Re: Pros and cons of high-level intermediate languages jfc@athena.mit.edu (1992-07-25)
Re: Pros and cons of high-level intermediate languages scott@bbx.basis.com (1992-07-25)
Re: Pros and cons of high-level intermediate languages sewardj@cs.man.ac.uk (1992-07-26)
[16 later articles]
| List of all articles for this month |

Newsgroups: comp.compilers
From: acha@CS.CMU.EDU (Anurag Acharya)
Organization: School of Computer Science, Carnegie Mellon University
Date: Fri, 24 Jul 1992 15:28:33 GMT
Keywords: storage, C, question
References: 92-07-068 92-07-074

Olivier.Ridoux@irisa.fr (Olivier Ridoux)
writes about something called abstract memory that solves problems relating
to GC as well as tail recursion.


I would like to know more about "abstract memory" and how it solves these
problems.


>>An optimistic final note. On one hand, the generated code seems to break
> the admitted dimensions of human programming: huge identifiers made of
> several layers of prefixes, tags or module names, huge expression (e.g. in
> our scheme the unification subprogram of every clause is made in a single
> conjunctive expression (&&)), etc.>On the other hand, it is hard knowing
> the limits of an actual C compiler. However, we never met them. In our
> experiments, we only met problems with cpp.


I am surprised. You must definitely be lucky. C compilers have a host of
limitations. Off the top of my head:


1. Size of individual functions
2. Number of cases in a switch statement (many compilers allow 500)
3. Number of typedefs ina file (one compiler had a quaint limit, 768. )
4. Size of source file
5. Size of static initializations
6. Number of symbols in initializations


Some compilers allow you to modify these limits by using obscure undocumented
options which differ from compiler to compiler.


Wish list:


1. label variables. Any kind of label variables with any resonable
restrictions


      (statically scoped, no jumping to inside blocks etc.). This would
      greatly facilitate compilation of both functional languages and parallel
      languages. It would also facilitate parallelizing compilers for other
      languages. To this, add a C compiler that does not limit the size
      of individual functions and you are close to using C as an assembly
      language


2. A portable way of looking at the stack. Supporting garbage collection
      and call/cc (user-level continuations) would be easier if one could
      traipse up and down the C stack. Currently, such schemes are machine and
      compiler dependent.


3. Some form of global register assignment. Some annotation scheme that
      allows me to indicate to the C compiler that I would like a particular
      global variable to be stuck in a register (may be a particular register
      if I am willing to give up portability).


anurag
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.