help-bison
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Query regarding Parser stack


From: Laurence Finston
Subject: Re: Query regarding Parser stack
Date: Sat, 30 Oct 2004 13:03:41 +0200 (MEST)

On Fri, 29 Oct 2004, Hans Aberg wrote:

> At 14:26 +0200 2004/10/12, Laurence Finston wrote:
> >> Can anybody please clarify that is there any other method to increase
> >> the stack size other than changing the static way?
>
> >The only forms of memory allocation are static (in the data segment of
> >the executable), automatic (on the program stack), and dynamic (on the
> >free store).
>

> There are a few more: In "registers", libraries, files, ... And these makes
> a difference when implementing a GC: For example, the "registers", which are
> used for temporaries (which may be allocated on the heap, despite the name),
> should be registered as root objects to a tracing GC, but (other) free store
> objects should not. The fact that one cannot distinguish between these in an
> automated manner in C++, makes it very difficult to implement a GC in C++
> (other than a reference count).

I suppose I should be more careful when I use the word "only".
However, I believe the _C Annotated Reference Manual_ recommends not
using the storage class specifier (correct term?) `register', giving
the reason that a good optimizing compiler will generally make better
decisions about what data should be stored in registers.
In addition, if such data is stored on the heap, then I doubt that
it's useful to consider this to be a truly different form of memory
allocation.

I don't understand what you mean by allocating memory in libraries.
Won't any memory allocated by objects or functions in libraries be
static, dynamic, or automatic, too?

I consider file i/o and memory allocation to be two different things.
For one thing, in order to read in data from a file, I must allocate
static, dynamic, or automatic memory for an object in
which to store it.

Laurence






reply via email to

[Prev in Thread] Current Thread [Next in Thread]