Re: Making 'eq' == 'eql' in bignum branch

[Paul Eggert]

Pip Cet wrote:
> That sounds promising! However, I wonder whether NaN-boxing isn't the
> right thing to do once we have bignums (on platforms that support it,
> by limiting pointers to 48 bits like x86-64 does).
I worry that NaN-boxing is less portable. Won't it have problems, for example, 
on a system that uses ASLR and where randomized virtual addresses exceed the 
2**52 limit?

I suppose, though, that if all the Javascript guys are doing NaN boxing then we 
can live in their shadow.
> the only real disadvantage is Qnil is no
> longer an all-zeroes pattern. I believe that's true for 61-bit float
> "immediates" as well, though, because they need the all-zero tag bits.

Actually, Qnil is still all-zeroes with my patch. XFLOAT removes the Lisp_Float 
tag bits before treating the resulting Lisp_Object value as a double. I expect 
this costs an instruction with XFLOAT, and that it's worth it to keep NILP fast.

We can play a similar trick with NaN boxing, so that Qnil is all-zeros there 
too. For example, we could complement all the bits in a Lisp_Object value before 
treating it as a double. So I don't view this as being a major advantage for the 
approach I suggested.

> I also wonder how many of the non-immediate floats are infinities, or
> other numbers that have all low-order mantissa bits set.

Infinities have the significand bits all zero, no? I'm skeptical that this is a 
profitable way to explore.

> I don't see how any of this applies to
> 32-bit platforms with 32-bit EMACS_INTs. On those, we cannot have
> float immediates or NaN boxing.

We can if we're willing to limit ourselves to 'float' precision for Emacs floats 
and at most 2**22-or-so distinct non-numeric objects. That might be doable. 
However I would rather not spend a lot of time worrying about tuning 32-bit 
EMACS_INT platforms.
> 61-bit floats would mean
> giving up IEEE compliance and surprising the occasional user who wants
> it. That's a very high price to pay for saving a few GCs.

RMS had a different opinion; he didn't think full IEEE compliance was worth all 
that much trouble <https://debbugs.gnu.org/32405#47>. Although I was originally 
striving for IEEE compliance, I'm becoming more inclined to try things along 
those lines as it should indeed be faster and I doubt whether Emacs users care 
all that much about full IEEE.