[Gcl-devel] Re: 32bit GCL

[Matt Kaufmann]

Hi, Camm --

I've just grabbed the latest cvs version of GCL 2.6.8pre and built
ACL2 with it, on my Intel Mac running Mac OS 10.6.4.  The build
succeeded, as did a run of the ACL2 regression suite (using a
development copy of ACL2, not much different from ACL2 4.0) -- well,
almost.  (But almost is still great -- thanks!)  Here's the story.

I first removed the progn form near the end of source file init.lisp
that contains the form

(setq si::*multiply-stacks* 2)

because that form caused an error (though maybe the build would have
succeeded; I'm not sure).  Here's a simple log from my Mac, not
involving ACL2:

  ~$ /Users/kaufmann/lisps/gcl/gcl-2.6.8pre/unixport/saved_gcl
  GCL (GNU Common Lisp)  2.6.8 CLtL1    Aug  6 2010 11:51:51
  Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
  Binary License:  GPL due to GPL'ed components: (READLINE UNEXEC)
  Modifications of this banner must retain notice of a compatible license
  Dedicated to the memory of W. Schelter

  Use (help) to get some basic information on how to use GCL.
  Temporary directory for compiler files set to 
/var/folders/6S/6ScqCriVFE8aH0vpDjfNK++++TI/-Tmp-/

  >(setq si::*multiply-stacks* 2)

  2

  >
  Error: Caught fatal error [memory may be damaged]
  Fast links are on: do (si::use-fast-links nil) for debugging
  Error signalled by an anonymous function.

  Error: 4 is an illegal ihs index.
  Fast links are on: do (si::use-fast-links nil) for debugging
  Error signalled by SYSTEM:UNIVERSAL-ERROR-HANDLER.
  Broken at SYSTEM:SCH-FRS-BASE.
  >>>:b
  Backtrace: system:universal-error-handler > SYSTEM:SCH-FRS-BASE
  NIL
  >>>

Perhaps there's a different way I should increase stack size?  One
regression test failed, namely books/serialize/serialize-tests.lisp,
with "Invocation history stack overflow.".  I'm guessing it's because
I didn't double the stack size, though I'm not sure.

Thanks --
-- Matt
   Cc: address@hidden, address@hidden, Robert Krug <address@hidden>
   From: Camm Maguire <address@hidden>
   Date: Fri, 06 Aug 2010 15:12:15 -0400
   X-SpamAssassin-Status: No, hits=-2.6 required=5.0
   X-UTCS-Spam-Status: No, hits=-252 required=165

   Greetings!  Wonderful to hear from you too!

   "Warren A. Hunt Jr." <address@hidden> writes:

   > Hi Camm,
   >
   > It's good to hear that you are back at work on GCL.
   >
   >   It appears we're getting close to a gcl release.  You might recall out
   >   [typo?; probably should be be "our"]
   >   having used static builds in the past to enable 32bit linux machines
   >   to use up to 3gig memory as opposed to the usual 1gig limit (imposed
   >   by the load address of shared libraries.)  Warren told me at one time
   >   that this was useful in getting the most out of 32bit, especially as
   >   64bit comes with its own overhead of bigger pointers.  In addition,
   >   the binary of course is completely portable.  Is this important to
   >   support?  There appear to have been some libc developments which will
   >   have to be worked around to get it working now.
   >
   > I believe there will be interest in 32-bit computing
   > for many years to come; I believe the embedded world of
   > computing will become almost entirely based on 32-bit
   > ARM and X86 platforms.  The number of embedded systems
   > (phones, tablets, set-top boxes, utility meters, etc.)
   > far exceeds the number of general-purpose computing
   > systems.  For instance, the device that measures the
   > electric power used in my home is an embedded Linux
   > system running on a Pico ITX board with a X86
   > processor.  So, for embedded computing, I think getting
   > what one can from the 32-bit X86 architecture is
   > valuable.
   >
   > Some years ago, Boyer and I didn't have ready access to
   > 64-bit computers so we were motivated to get as much
   > out of our 32-bit computers as possible.  However, now
   > even my laptop contains a 64-bit (Intel Core 2 Duo)
   > microprocessor with 8 GBytes RAM, so now I always work
   > on a 64-bit machine.  Therefore, I don't expect to be a
   > future customer of 32-bit GCL for general-purpose
   > computing.
   >

   Good thing then I guess that I put in the extra work to get 64bit
   working on the mac.  There is a special configure option needed as
   explained in README.macosx.  The standard configure tools detect the
   box as 32bit by default.

   In any case, this mac stuff appears done now.  If anyone finds it
   useful enough to try it out and report back, that of course would be
   great.  No need of course unless it is of genuine use to some real mac
   user. 

   Take care,

   > Cheers,
   >
   > Warren
   >
   >
   >
   >

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