🚀 go-pugleaf

| We've had some trouble with Epoch on HP9000s800's, and I tracked it down to the
| following defines in m-hp9000s800.h, which are identical to the ones in GNU
| Emacs 18.55:
| 
| #define XMARKBIT(a) ((a) < 0)
| #define XSETMARKBIT(a,b) ((a) = ((b) ? (a)|MARKBIT : (a) & ~MARKBIT))
| #define XUNMARK(a) ((a) = (((a) << INTBITS-GCTYPEBITS-VALBITS) >> \
|                            INTBITS-GCTYPEBITS-VALBITS))
| 
| 
| In addition, GCTYPEBITS is set to 5. What happens is that under Epoch, the
| top bit of the TYPE field can be 1 (because Epoch has more types than GNU
| Emacs). This bit gets left shifted to the top bit position, and then the
| right shift leaves the top bit (the GC mark bit) set, so that XUNMARK()
| does not actually unmark objects with type > 15.
| 
| What I'd like to know is, why are the macros defined this way? The comments
| claim that these are faster, but I find it difficult to believe that 2 shifts
| are faster than 1 mask on any architecture. Would getting rid of these
| defines and just using the defaults be a problem?

On some machines, GCC has special optimizations that change:

	*int_ptr >> 24			(on big endian systems)

to a single load byte instruction, which beats having to do a mask.
But of course, you have to get the type info into the correct byte
(ie, the #ifdef's in lisp.h), and it has to be 8 bits....

--
Michael Meissner	email: meissner@osf.org		phone: 617-621-8861
Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142

Considering the flames and intolerance, shouldn't USENET be spelled ABUSENET?