Re: data allocation in interpreters

haberg@math.su.se (Hans Aberg)
3 Jun 2006 18:52:50 -0400

          From comp.compilers

Related articles
data allocation in interpreters weltraum@astrocat.de (2006-05-30)
Re: data allocation in interpreters pjb@informatimago.com (Pascal Bourguignon) (2006-05-30)
Re: data allocation in interpreters haberg@math.su.se (2006-06-03)
Re: data allocation in interpreters georgeps@xmission.com (George Peter Staplin) (2006-06-03)
Re: data allocation in interpreters gmt@CS.Arizona.EDU (2006-06-07)
| List of all articles for this month |

From: haberg@math.su.se (Hans Aberg)
Newsgroups: comp.compilers
Date: 3 Jun 2006 18:52:50 -0400
Organization: Mathematics
References: 06-05-091 06-05-094
Keywords: interpreter, storage
Posted-Date: 03 Jun 2006 18:52:50 EDT

Pascal Bourguignon <pjb@informatimago.com> wrote:


> weltraum@astrocat.de writes:
> > What are common techniques for data allocation (strings, high-level
> > data structures) in interpreters?


> > What do you think, how is it implemented in the famous interpreters?


> Depends on the programming language.


As you say, it depends on the programming language used, but also on the
ambition level of the interpreter implementation. If one is a singly
implementer, it might be suitable with a programming language like C++
plus the use of a reference count - C++ does not currently support
the implementations of any other GC (the Boehm GC goes in a a layer
between the compiler and the platform), but the next revision might. If
using Java/Objective C, one can get this cleanup via the language.


> But in most other programming languages, there's a garbage collector.


For a more optimized interpreter, C is the better choice, and an
interpreter like Hugs <http://haskell.org/hugs/> uses a two-space copying
GC. I think this is typical choice of GC for many interpreters, at
least before more advanced forms of GC are considered.


--
    Hans Aberg


Post a followup to this message

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