Re: [Emacs-diffs] /srv/bzr/emacs/trunk r107377: * src/lisp.h: Improve comment about USE_LSB_TAG.

[Stefan Monnier]

> +/* On hosts where VALBITS is greater than the pointer width in bits,
> +   USE_LSB_TAG is:
> +    a. unnecessary, because the top bits of an EMACS_INT are unused,
> +    b. slower, because it typically requires extra masking, and

Is this just a gut-feeling, or is there some actual measurement behind
this assertion?

What kind of extra masking are you referring to?  The XFASTINT?
Note that the LSB masking can be cheaper than the MSB masking (because
the mask is a smaller value which fits more easily in an immediate
value).

I haven't made any measurements (the motivation for LSB tags was not
speed but addressing range), but I'd find it surprising if LSB tags are
generally slower.

> +    c. harmful, because it can create Lisp_Object values that are so 
> scrambled
> +       that mark_maybe_object cannot decipher them.  mark_maybe_object 
> assumes
> +       that EMACS_INT values are contiguous, but a host where EMACS_INT is
> +       wider than a pointer might allocate the top half of an EMACS_INT in
> +       (say) a 32-bit word on the stack, putting the bottom half in a 32-bit
> +       register that is saved elsewhere in a jmp_buf.  When this happens,
> +       since USE_LSB_TAG is not defined the bottom half alone is a valid
> +       pointer that mark_maybe_pointer can follow; but if USE_LSB_TAG were
> +       defined, the bottom half would not be a valid pointer and neither
> +       mark_maybe_object nor mark_maybe_pointer would follow it.

I see.  So "VALBITS is greater than the pointer width in bits" is not
the exactly right condition (e.g. if we have 48bit pointers and 61
VALBITS then the problem should not appear).

Maybe a better fix is to add code to the stack marking loop, conditional
on WIDE_EMACS_INT and USE_LSB_TAGS, which passes pointer-sized
words to mark_maybe_object after expanding them to EMACS_INT size.


        Stefan