Re: pdumper on Solaris 10

[Pip Cet]

"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. What do you disagree with? Which mysterious "other registers" do
you mean? Why do you think I "forget" about them, with the implication
that I do not understand the x86 architecture?

(Of course I'm not forgetting about other registers: x87 FPU registers
(which mishandle NaN bit patterns), MMX registers (which are unusable
because FPU might be in use), and XMM registers (which do not support
integer comparisons setting flags) are all irrelevant in the context
we're discussing.  I know you know this, which makes your statement even
less appropriate.)

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'll post about it in a separate thread once I've decided on a few minor
issues:

1. what to do about native compilation.  The native compilation code
currently produces incorrect code and obviously it is (or should be) a
priority to fix that before touching the code in other ways.
2. whether to avoid using GMP for "small" bignums.  It would save some
memory. This would require an extra tag which would reduce the fixnum
range by one bit.
3. what to do about most-positive-fixnum and most-negative-fixnum. These
are the only places that "leak" the size of a fixnum to Lisp in the new
code, and it's not clear whether we should return the most positive
fixnum that fits into a Lisp_Object or the most positive "small bignum",
or maybe always return the 62-bit most-positive-fixnum.

Pip