[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