gcl-devel
[Top][All Lists]
Advanced

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

[Gcl-devel] Re: hi


From: Camm Maguire
Subject: [Gcl-devel] Re: hi
Date: 10 Aug 2006 14:03:57 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Greetings!

Robert Boyer <address@hidden> writes:

> > Did not know that there was a system configuration reason for this --
> > thought instead that the driver behind static was that twice the memory
> > on 64bit is required to get the same heap as on 32bit.
> 
> You are absolutely right that going static has a wonderful advantage of
> allowing greater memory use of a 32 bit machine under GCL.
> 
> But there are still so many problems associated with static that I fear
> for its GCL future.  E.g., those functions that, when one calls them,
> cause GCL simply to die because of various wars over what goes where
> dynamically and statically.  E.g., worrying about going this way and
> then that way for tcl/tk.  I don't think that there is yet a static X
> windows GCL 2.7.0, right?  It will probably be a great liberation to you
> if I stop using static gcl!  Static is a sufficient pain that I'll
> switch over to using a 64 bit Harper type machine rather than using
> elgin, exclusively, if things go the way I hope.
> 

Agreed this is quite messy, but it appears that it will always be
useful given one's increasing inabitlity to control the memory layout
of one's machine.  I'm hoping if we can eliminate all reference to any
problem C functions in the code and use some helper program, and do
likewise with gcltkaux, we'll basically be stable.  And I know there
is at least one outstanding issue in thie regard you've sent to me
some time ago -- will try to dig this up and fix it.

> Now, what we need to do is start working on you to invent the one word
> cons!  That is, pairing two 32-bit words together into one 64-bit word
> so that conses do not take up too much space, e.g., at least not until
> it makes sense in a particular process.  I mean, if someone does not
> have more than, say, a billion Lisp objects around, then one doesn't
> really need to use 64 bits for a cons.  And thus one could get twice the
> use of one's memory for a while.  Of course, this may be an irrational
> line of thought, especially if we want immediate 61 bit fixnums.  But
> then, ..., one could check at cons time whether a 29 bit fixnum would
> suffice.

Would be interested to know 

1) what is cdr-coding?
2) what is the performance hit on manipulating half-words?  I.e. is
   there any other program with experience here?

Take care,

> 
> Bob
> 
> "Poetry is the art of creating imaginary gardens with real toads."
> Marianne Moore.
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah




reply via email to

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