Re: pdumper on Solaris 10

[Eli Zaretskii <eliz@gnu.org>]

> Date: Tue, 17 Dec 2024 13:12:57 +0000
> From: Pip Cet <pipcet@protonmail.com>
> Cc: luangruo@yahoo.com, ali_gnu2@emvision.com, emacs-devel@gnu.org
> 
> "Eli Zaretskii" <eliz@gnu.org> writes:
> 
> >> > Modern x86 CPUs can handle 64-bit values just fine, thank you.
> >>
> >> Modern x86 CPUs running 32-bit code (x86, not x32) still need two
> >> register names for each 64-bit value.  With 8 GPRs, that's a significant
> >> problem. So, no, "just fine" isn't accurate here.
> >
> > I again disagree.  And you forget other registers.
> 
> I think this is a perfect example of why discussions with Eli are so
> hard.

You always have an option not to argue.

> As for the actual problem, I've continued working on this, and I believe
> I've come up with a solution which
> 
> 1. drops WIDE_EMACS_INT
> 2. drops !USE_LSB_TAG
> 3. allows the use of "small bignums" for buffer and string positions
> 4. makes eq = eql for "small bignums", where appropriate
> 5. adjusts the hash table code to do the same
> 6. enables us to introduce further "exotic" objects (non-trivial 'eq')
> 7. speeds up and simplifies EQ by branching on a tag bit rather than a
> global variable
> 8. possibly (see below) reduces the fixnum range by one bit (invisible to users)

I don't like this solution, because it again will cause us a lot of
code churn for very little gain.  How many people use WIDE_EMACS_INT
these days?  I could be the only one.  That code works, and works well
enough.  Certainly well enough for me, and I have yet to hear
complaints from anyone else.  And !USE_LSB_TAG was dropped in the igc
code, so when we merge that, every platform which uses MPS will not
have !USE_LSB_TAG.

So what is left is to remove WIDE_EMACS_INT, which we should do in
some not too distant future, when its last user (yours truly) retires
his 32-bit development environment.  (We should announce this
prominently and enough time in advance, so that in the unlikely case
that there are any other users of that configuration, they will have
ample opportunity to try to convince us to delay or rethink.)

So my suggestion is that you stop wasting your time on the above,
because I'm not interested in considering such significant changes for
so little gain.  What you did on the igc branch regarding
WIDE_EMACS_INT and !USE_LSB_TAG (thanks!) should be enough for us, and
let's turn our attention and resources to more promising directions.

Thanks.