Re: The C Stack in interpreters - why?

haberg@math.su.se (Hans Aberg)
14 May 2005 12:17:57 -0400

          From comp.compilers

Related articles
The C Stack in interpreters - why? clearm@comcast.net (2005-05-13)
Re: The C Stack in interpreters - why? Peter_Flass@Yahoo.com (Peter Flass) (2005-05-14)
Re: The C Stack in interpreters - why? haberg@math.su.se (2005-05-14)
Re: The C Stack in interpreters - why? clearm@comcast.net (2005-05-14)
Re: The C Stack in interpreters - why? nmm1@cus.cam.ac.uk (2005-05-14)
Re: The C Stack in interpreters - why? anton@mips.complang.tuwien.ac.at (2005-05-14)
Re: The C Stack in interpreters - why? haberg@math.su.se (2005-05-14)
Re: The C Stack in interpreters - why? nmm1@cus.cam.ac.uk (2005-05-14)
Re: The C Stack in interpreters - why? Marko.Makela@HUT.FI (Marko =?ISO-8859-1?Q?M=E4kel=E4?=) (2005-05-14)
Re: The C Stack in interpreters - why? marcov@stack.nl (Marco van de Voort) (2005-05-14)
Re: The C Stack in interpreters - why? gah@ugcs.caltech.edu (glen herrmannsfeldt) (2005-05-15)
Re: The C Stack in interpreters - why? gene@abhost.us (Gene Wirchenko) (2005-05-15)
Re: The C Stack in interpreters - why? nmm1@cus.cam.ac.uk (2005-05-15)
[3 later articles]
| List of all articles for this month |
From: haberg@math.su.se (Hans Aberg)
Newsgroups: comp.compilers
Date: 14 May 2005 12:17:57 -0400
Organization: Mathematics
References: 05-05-072 05-05-079
Keywords: interpreter, architecture
Posted-Date: 14 May 2005 12:17:57 EDT

clearm@comcast.net wrote:


> Answer 2: Fortunately, there is Stackless Python, which has a
> completely redesigned interpreter loop that avoids the C stack. It's
> still experimental but looks very promising."
> [That's the hardware stack on computers that have one. The point
> they're making is that if you use the regular call stack and want to
> do threads in your interpreter, you need a thread package that will
> thread at the C level. ... -John]


Again, this might depend on the OS:


Modern UNIX computers often have a microkernel, being able to handle
threads. For example, BSD often uses a Mach kernel. If one has Mach on
ones computer, then one can doe threading from C, by invoking some Mach
headers. See for example the book Boykin, Kirschen, Langerman & LoVerso,
"Programming under Mach". So if threading is the reason, and you have a
threading capable microkernel, then it should be better to use the one
supplied by the system.


Another reason to avoid using the function parameter stack might be that
in the past, it was slow. It is probably not a reason anymore, but
particularly when implementing a functional language, the stack can grow
quite a lot. So one may want to implement a complement to the hardware
parameter stack. One then in actuality comes up with a hybrid, which calls
the parameter stack less often, but still uses it. This was done in the
implementation of Hugs http://haskell.org/hugs. I have used a similar
technique myself. The technique is as follows:


If a function does not need to save some parameters on the stack, but just
needs to call another function, then one can have a small evaluation loop
lying above the function, looking for the return of function pointers. If
the function returns a function pointer, the loop will execute it. This
leads to the implementation of a tail recursive engine. It is described in
the book by Abelson and Sussman, "Structures and the Implementation of
Computer Programs". But one can play this game on essentially any
function, by putting the data that the function uses locally, and would
prevent this tail recursion eveluation technique, elsewhere: on some other
stack, or on the heap. If you do that, I think you end up with what is a
"stackless" (non-threaded) engine.


--
    Hans Aberg
[I don't think any current version of BSD still is built on Mach, but
they all have thread support in the kernel. -John]



Post a followup to this message

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