From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.emacs.devel Subject: Re: emacs and guile (Re: ehelp woes, or why I hate a module that I love so much) Date: Thu, 18 Jul 2002 16:13:58 -0400 Sender: emacs-devel-admin@gnu.org Message-ID: References: <20020704135240.4CBB.LEKTU@terra.es> <20020704164911.4CC1.LEKTU@terra.es> <200207181455.g6IEtvc25102@aztec.santafe.edu> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1027025545 17321 127.0.0.1 (18 Jul 2002 20:52:25 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 18 Jul 2002 20:52:25 +0000 (UTC) Cc: emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 17VIG8-0004VG-00 for ; Thu, 18 Jul 2002 22:52:24 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17VISB-0007rU-00 for ; Thu, 18 Jul 2002 23:04:52 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.35 #1 (Debian)) id 17VIFy-0000Ei-00; Thu, 18 Jul 2002 16:52:14 -0400 Original-Received: from delysid.gnu.org ([158.121.106.20]) by fencepost.gnu.org with esmtp (Exim 3.35 #1 (Debian)) id 17VIEW-0008Rw-00; Thu, 18 Jul 2002 16:50:45 -0400 Original-Received: from 208-59-178-90.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com ([208.59.178.90] helo=raeburn.org) by delysid.gnu.org with esmtp (Exim 3.34 #2) id 17VHjn-00048T-00; Thu, 18 Jul 2002 16:18:59 -0400 Original-Received: from kal-el.raeburn.org ([2002:d03b:b25a:1:201:2ff:fe23:e26d]) by raeburn.org (8.11.3/8.11.3) with ESMTP id g6IKDxf04223; Thu, 18 Jul 2002 16:13:59 -0400 (EDT) Original-Received: from raeburn by kal-el.raeburn.org with local (Exim 3.35 #1 (Debian)) id 17VHew-0008IZ-00; Thu, 18 Jul 2002 16:13:58 -0400 Original-To: rms@gnu.org In-Reply-To: <200207181455.g6IEtvc25102@aztec.santafe.edu> (Richard Stallman's message of "Thu, 18 Jul 2002 08:55:57 -0600 (MDT)") Original-Lines: 91 User-Agent: Gnus/5.090005 (Oort Gnus v0.05) Emacs/21.1.50 (i686-pc-linux-gnu) Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:5874 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:5874 > (BTW, I've got a patch that adds configures option to turn on > ENABLE_CHECKING, or just the use of a union for Lisp_Object. Should I > check it in? > > Could you show us what it looks like? A patch file is appended with my current configure.in changes. The ENABLE_CHECKING and USE_LISP_UNION_TYPE macros are already tested in lisp.h. The CONFIG_NO_DUMP stuff probably isn't of interest, but when I start playing with Guile again I don't want to have to assume from the start that libguile is unexec-safe. Those changes (and a related one in src/Makefile.in) are just there so I can test the no-unexec case separately from the Guile work. > Use of the union type caused the code to be much slower, with typical > Unix compilers in the 80s. GCC might do a better job with it, but I think > it is an interesting question whether the compiled code for Emacs is as good > when using the union type as it is when using an integer type. What have > you observed? It is still going to be slightly slower than using integer types anywhere a word-sized union is passed or returned by reference. I wouldn't recommend it as a default, because we want all the speed we can reasonably get, but it's not that painful to use. I haven't tried any timing tests, but it would be an interesting experiment to do with modern compilers on various platforms. I'm also not using it in the Emacs binary I use daily, but I did have to check to figure that out. I'll try switching (it's about time I update to current-CVS again anyways) and see if it's a problem. Index: configure.in =================================================================== RCS file: /cvsroot/emacs/emacs/configure.in,v retrieving revision 1.300 diff -p -u -r1.300 configure.in --- configure.in 21 Jun 2002 20:57:54 -0000 1.300 +++ configure.in 18 Jul 2002 19:01:15 -0000 @@ -132,6 +132,24 @@ AC_ARG_WITH(xim, AC_ARG_WITH(carbon, [ --without-carbon don't use Carbon GUI on Mac OS X]) +AC_ARG_ENABLE(checking, +[ --enable-checking turn on expensive internal run-time consistency + checks (not recommended unless debugging Emacs)]) +if test "${enable_checking}" = yes ; then + AC_DEFINE(ENABLE_CHECKING) +fi +AC_ARG_WITH(union-type, +[ --with-union-type use union type for lisp object representation + (slows performance, better compile-time checks)]) +if test "${with_union_type}" = yes ; then + AC_DEFINE(USE_LISP_UNION_TYPE) +fi +AC_ARG_ENABLE(unexec, +[ --disable-unexec don't generate "dumped" Emacs with pre-loaded lisp]) +if test "${enable_unexec}" = no ; then + AC_DEFINE(CONFIG_NO_DUMP) +fi + #### Make srcdir absolute, if it isn't already. It's important to #### avoid running the path through pwd unnecessarily, since pwd can #### give you automounter prefixes, which can go away. We do all this Index: src/config.in =================================================================== RCS file: /cvsroot/emacs/emacs/src/config.in,v retrieving revision 1.174 diff -p -u -r1.174 config.in --- src/config.in 1 May 2002 04:30:59 -0000 1.174 +++ src/config.in 18 Jul 2002 19:01:17 -0000 @@ -916,6 +916,12 @@ extern char *getenv (); #define HAVE_X11R6_XIM #endif +/* Force use of union type for Lisp_Object? */ +#undef USE_LISP_UNION_TYPE + +/* Disable unexec code? */ +#undef CONFIG_NO_DUMP + /* Should we enable expensive run-time checking of data types? */ #undef ENABLE_CHECKING