unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Ken Raeburn <raeburn@raeburn.org>
Cc: emacs-devel@gnu.org
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	[thread overview]
Message-ID: <tx1wursvlo9.fsf@raeburn.org> (raw)
In-Reply-To: <200207181455.g6IEtvc25102@aztec.santafe.edu> (Richard Stallman's message of "Thu, 18 Jul 2002 08:55:57 -0600 (MDT)")


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

  reply	other threads:[~2002-07-18 20:13 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-06-25 14:50 ehelp woes, or why I hate a module that I love so much Juanma Barranquero
2002-06-25 15:06 ` D. Goel
2002-06-25 15:41   ` Juanma Barranquero
2002-06-26 22:24 ` Richard Stallman
2002-06-27 17:11   ` Juanma Barranquero
2002-06-27 19:57     ` Stefan Monnier
2002-07-02 15:02       ` Juanma Barranquero
2002-07-02 15:18         ` Stefan Monnier
2002-07-02 15:50           ` Juanma Barranquero
2002-06-29  8:41     ` Richard Stallman
2002-07-02 15:15       ` Juanma Barranquero
2002-07-02 15:49         ` Eli Zaretskii
2002-07-03 11:16           ` Juanma Barranquero
2002-07-03 20:57         ` Richard Stallman
2002-07-03 21:32           ` Simon Josefsson
2002-07-04  5:09             ` Eli Zaretskii
2002-07-04  7:58           ` Juanma Barranquero
2002-07-04 10:13             ` Eli Zaretskii
2002-07-04 11:52               ` Juanma Barranquero
2002-07-06 10:38                 ` Eli Zaretskii
2002-07-04 11:02             ` Simon Josefsson
2002-07-04 12:08               ` Juanma Barranquero
2002-07-04 12:19                 ` Miles Bader
2002-07-04 13:31                   ` Juanma Barranquero
2002-07-04 14:02                   ` Simon Josefsson
2002-07-04 14:00                 ` Simon Josefsson
2002-07-04 15:20                   ` Juanma Barranquero
2002-07-17  2:58                     ` emacs and guile (Re: ehelp woes, or why I hate a module that I love so much) Ken Raeburn
2002-07-17  7:13                       ` Juanma Barranquero
2002-07-17  9:11                       ` Kai Großjohann
2002-07-18 14:54                         ` Richard Stallman
2002-07-18 21:45                         ` Ken Raeburn
2002-07-18 14:55                       ` Richard Stallman
2002-07-18 20:13                         ` Ken Raeburn [this message]
2002-07-19 13:03                           ` Andreas Schwab
2002-07-19 16:24                             ` Ken Raeburn
2002-07-19 16:54                           ` Richard Stallman
2002-07-19 17:51                             ` Ken Raeburn
2002-07-18 14:56                       ` Richard Stallman
2002-07-18 19:54                         ` Ken Raeburn
2002-07-19  4:23                           ` Stefan Monnier
2002-07-19 12:56                             ` Ken Raeburn
2002-07-19 13:34                               ` Stefan Monnier
2002-07-19 14:16                                 ` Andreas Schwab
2002-07-19 15:04                                   ` Stefan Monnier
2002-07-19 16:54                           ` Richard Stallman
2002-07-19 17:48                             ` Ken Raeburn
2002-07-19 18:25                             ` Marius Vollmer
2002-07-20  0:35                               ` Richard Stallman
2002-07-20 12:00                                 ` Marius Vollmer
2002-07-21 20:14                                   ` Richard Stallman
2002-07-19 16:54                           ` Richard Stallman
2002-07-04 19:07             ` ehelp woes, or why I hate a module that I love so much Henrik Enberg
2002-07-05  0:49               ` Juanma Barranquero
2002-07-05 11:15                 ` Per Abrahamsen
2002-07-05 10:48             ` Richard Stallman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=tx1wursvlo9.fsf@raeburn.org \
    --to=raeburn@raeburn.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).