[Don't try to apply it Steven, it will fail, I reindented :-)]
Given that with minimal tagbits pointers are clean, this patch is ok,
right?
(it seems to work, but I wonder why it wasn't done in the first place
since afair Kyle did talk about removal of pointer masking in her
speed comparisons)
Martin: You may want to try such a thing in your speed quest, this
removes a lot of 'or' operations on some architectures. DATA_SEG_BITS
are used on SGI too.
OG.
Index: lisp.h
===================================================================
RCS file: /usr/CVSroot/XEmacs/xemacs-20/src/lisp.h,v
retrieving revision 1.38
diff -u -r1.38 lisp.h
+#ifndef USE_MINIMAL_TAGBITS
# ifdef HAVE_SHM
/* In this representation, data is found in two widely separated segments. */
extern int pure_size;
# define XPNTR(x) \
((void *)(XPNTRVAL(x)) | (XPNTRVAL(x) > pure_size ? DATA_SEG_BITS : PURE_SEG_BITS)))
# else /* not HAVE_SHM */
# ifdef DATA_SEG_BITS
/* This case is used for the rt-pc and hp-pa.
In the diffs I was given, it checked for ptr = 0
and did not adjust it in that case.
But I don't think that zero should ever be found
in a Lisp object whose data type says it points to something.
*/
# define XPNTR(x) ((void *)((XPNTRVAL(x)) | DATA_SEG_BITS))
# else /* not DATA_SEG_BITS */
# define XPNTR(x) ((void *) (XPNTRVAL(x)))
# endif /* not DATA_SEG_BITS */
# endif /* not HAVE_SHM */
+#else /* USE_MINIMAL_TAGBITS */
+# define XPNTR(x) ((void *) (XPNTRVAL(x)))
+#endif
