[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gcl-devel] 2.6.1-8
From: |
Camm Maguire |
Subject: |
[Gcl-devel] 2.6.1-8 |
Date: |
14 Sep 2003 10:11:40 -0400 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 |
Greetings! Just a brief note on a few developments:
1) I've renamed the lsp and cmpnew files, and the init_* functions in
o, largely in response to function name conflicts when building
axiom with compiler::link. The idea is that we reserve as much of
the init_.... function namespace as possibly for the user. In o/,
this is done by init_* -> gcl_init_*; in lsp and cmpnew we take for
ourselves functions of the name init_gcl_*. Remember we did
similarly with pcl_ and clcs_ prefixes when putting together the
ansi build. At some point we should homogenize to gcl_pcl_ and
gcl_clcs_, but this is left for a future date.
If for example a user has a module named hash, GCL will call the
init function init_code if :system-p is not set, and init_hash
otherwise. The former can be linked in just fine with fasload, but
not with ld, as init_code will be multiply defined. On dlopen
systems without fasload, (ia64, alpha, mips(el), hppa), one has to
resort to ld linking via compiler::link at present, and therefore
must have uniquely named compiled lisp modules.
As before, we hope the absence of fasload on these platforms is
temporary. Its really a question of bfd supporting its function
bfd_get_relocated_section_contents on these machines. As there are
really only three open source apps using GCL at present which need
this portability (for purposes of inclusion in standard
distributions like Debian), the present setup is manageable, but
requires someone (like me) patching the build process (e.g. for
maxima, acl2, and axiom) to use compiler::link when appropriate.
It would be great if this was completely transparent to the user.
We're not that far away. Consider the following patch for axiom
for instance:
- @ (cd ${OBJ}/${SYS}/bin ; \
- echo '(progn (gbc t) (load "${OUT}/makeint.lisp") (gbc t)
(user::spad-save "${SAVESYS}"))' | ${LISPSYS} )
+# @ (cd ${OBJ}/${SYS}/bin ; \
+# echo '(progn (gbc t) (load "${OUT}/makeint.lisp") (gbc t)
(user::spad-save "${SAVESYS}"))' | ${LISPSYS} )
+ @ (cd ${MNT}/${SYS}/bin && \
+ echo '(setq si::*collect-binary-modules* t)(setq x
si::*system-directory*)(load "${OUT}/makeint.lisp")(setq si::*system-directory*
x)(compiler::link (remove-duplicates si::*binary-modules* :test (quote equal))
"$(SAVESYS)" "(setq si::*collect-binary-modules* t)(load
\"$(OUT)/makeint.lisp\")(when si::*binary-modules* (error
si::*binary-modules*)(setq si::collect-binary-modules* nil si::*binary-modules*
nil)(setq compiler::*default-system-p* t)(gbc t))"
"$(OBJ)/$(SYS)/lib/sockio-c.o $(OBJ)/$(SYS)/lib/cfuns-c.o
$(OBJ)/$(SYS)/lib/libspad.a" nil)' | ${LISPSYS})
I've added a facility for collecting a list of fasloaded binary
modules for use in compiler::link. when
si::*collect-binary-modules* is set to t, si::*binary-modules* will
have a list of loaded .o files. compiler:link takes this list as
its first argument, and compiles using ld a 'raw' image made up of
all gcl objects (in libgcl.a et.al) and these specified .o files.
It then runs the raw image with the gcl init script as input
(init_gcl.lsp), appending to that file the third argument of
compiler::link. This basically just loads the user init file
again. When the load of the .o files is attempted, GCL notices
that they've already been compiled in, and a running of their init
sequence is executed instead. We collect the binary module list
again to make sure that no actual fasloads have been performed, and
then save the system via unexec. The second argument is the output
file, the fourth argument are extra C libraries needed for ld, and
the last is a flag specifying whether to explicitly initialize the
user .o files, or to let the fasload->init redirect do it
automatically instead.
So in principle, we could make save-system perform these steps on
non-fasload systems, *if it can collect user input/initialization
code* to be fed again to the raw image. It may be possible to
instruct the reader to make a copy of input as it is parsed, in
which case the above patch would be obviated.
The problem of course in on multiple cycles of load, save, exec.
All user .o files must be found in their original locations at each
save invocation, and the binary-module list must not be tampered
with. In addition, the system-p flag must be set, most easily via
compiler::*default-system-p*.
Personally, I'm not sure that greater transparency is worth the
effort at present, considering that the machines in question appear
to be rarely used, the application load is (currently) small, and
that we can hope for bfd improvements. But this is how it might
go.
In any case, I'd appreciate feedback on the naming conventions of
our installed files. I haven't modified the gcl-tk files for
example, as they always appear to be fasloaded, but one might want
to compile these in as well too someday. We could use some
standardization.
2) Compressed info file reading should be working now. I've removed
the extra set of uncompressed info files from the Debian package.
3) There is a persistent gcc bug on ppc which will not allow
compilation of new_init.c with full optimization. Furthermore,
there appears to be a highly image specific bug in strip on that
platform as well. I've added workarounds.
4) I've started work on a temporary alternate mirror site (very much
in progress) to be found at http://people.debian.org/~camm/gcl.
I'll add a link on our main page and try to incorporate Matt's
instructions when this is complete. When ftp.gnu.org becomes
available again, we'll transfer this location.
Take care,
--
Camm Maguire address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah