gcl-devel
[Top][All Lists]
Advanced

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

[Gcl-devel] Regarding the release...


From: Camm Maguire
Subject: [Gcl-devel] Regarding the release...
Date: 27 Feb 2003 19:22:39 -0500
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Greetings!  Well, I'm sure we may have a few more minor issues, but
current CVS works as follows for me:

1) Successfully compiles in 4 basic flavors, ansi/trad, bfd/dlopen
2) Compiles itself
3) Runs Paul's suite in the ansi case identically in both cases
4) Compiles maxima with successful make check in all 4 flavors
5) Builds acl2 successfully in trad flavor (needed by acl2 design)
6) Debian package builds and ships both images, and uses environment
        variable GCL_ANSI to toggle behavior
7) Build of both will work in principal on all 11 Debian arches
        (waiting for confirmation from autobuilders, 64 bit ia64 and
        alpha tested positively by hand)
8) The Debian package will now run Paul's suite on all platforms, so
        we can make comparisons.  All look identical thus far.

Some issues that I've discovered:

1) Earlier reported difference in maxima compilation was due to
   maxima's eliminating their sys-proclaims if :ansi-cl is defined.
   Eliminating that 'elimination' gives the same (basically, see below)
   C files as the traditional case.

2) I thought that this would be the performance culprit for ansi
   maxima, but it does instead appear to be due to the size of the
   ansi image.  maxima make check runs about 20% slower with ansi.

3) pcl and clcs files still need to be rebuilt from lisp, as there are
   arch specific constants written into the C files, (I only noticed
   STREF offsets).  This observation also led to some 64bit structure
   debugging.  All looks good now on 64bit, both traditional and ansi.

4) There is a compiler bug in the volatile variable detection,
   necessitating a makefile applied patch of pcl_methods.c for now.
   If anyone wants to look into this, grep on setjmp and volatile in
   cmpnew/*lsp.  The idea is that variables cannot be put into
   registers if they are used in a block which could be accessed via a
   longjmp, i.e. throw/catch.  The code that does this in gcl C files
   manipulate the frs stack and are thus labelled.

5) There is an (apparently small) compilation output difference
   between the ansi and traditional images.  The ANSI writes certain
   closures with the 'turbo closure' mechanism, which looks to be an
   improvement.  Until this is adequately tested, the makefiles use
   the traditional image to rebuild the lsp and cmpnew core C files.


I'm going to tag this any minute now as 2.5.1.  Tomorrow is the last
day I'll be able to do anything official.  But it looks quite good
now.  Congratulations to all!

P.S. If anyone would like to write a short blurb about the release,
I'd be most grateful.

Take care,


-- 
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]