[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: emacs and guile (Re: ehelp woes, or why I hate a module that I love
From: |
Ken Raeburn |
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 |
User-agent: |
Gnus/5.090005 (Oort Gnus v0.05) Emacs/21.1.50 (i686-pc-linux-gnu) |
> (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
- Re: emacs and guile (Re: ehelp woes, or why I hate a module that I love so much), (continued)
- Re: emacs and guile (Re: ehelp woes, or why I hate a module that I love so much), Richard Stallman, 2002/07/19
- Re: emacs and guile (Re: ehelp woes, or why I hate a module that I love so much), Ken Raeburn, 2002/07/19
- Re: emacs and guile (Re: ehelp woes, or why I hate a module that I love so much), Marius Vollmer, 2002/07/19
- Re: emacs and guile (Re: ehelp woes, or why I hate a module that I love so much), Richard Stallman, 2002/07/19
- Re: emacs and guile (Re: ehelp woes, or why I hate a module that I love so much), Marius Vollmer, 2002/07/20
- Re: emacs and guile (Re: ehelp woes, or why I hate a module that I love so much), Richard Stallman, 2002/07/21
- Re: emacs and guile (Re: ehelp woes, or why I hate a module that I love so much), Richard Stallman, 2002/07/19
- Re: emacs and guile (Re: ehelp woes, or why I hate a module that I love so much), Richard Stallman, 2002/07/18
- Re: emacs and guile (Re: ehelp woes, or why I hate a module that I love so much),
Ken Raeburn <=
- Re: emacs and guile (Re: ehelp woes, or why I hate a module that I love so much), Andreas Schwab, 2002/07/19
- Re: emacs and guile (Re: ehelp woes, or why I hate a module that I love so much), Ken Raeburn, 2002/07/19
- Re: emacs and guile (Re: ehelp woes, or why I hate a module that I love so much), Richard Stallman, 2002/07/19
- Re: emacs and guile (Re: ehelp woes, or why I hate a module that I love so much), Ken Raeburn, 2002/07/19
- Re: ehelp woes, or why I hate a module that I love so much, Henrik Enberg, 2002/07/04
- Re: ehelp woes, or why I hate a module that I love so much, Juanma Barranquero, 2002/07/04
- Re: ehelp woes, or why I hate a module that I love so much, Per Abrahamsen, 2002/07/05
- Re: ehelp woes, or why I hate a module that I love so much, Richard Stallman, 2002/07/05