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
next prev parent 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).