Re: pdumper on Solaris 10

["Gerd Möllmann" <gerd.moellmann@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Sun, 08 Dec 2024 17:37:50 +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:
>> 
>> >> So let's remove it, and switch WIDE_EMACS_INT builds to USE_LSB?
>> >
>> > That'd be a waste of effort.
>> 
>> It'd be a good investment of effort today, in exchange for making the GC
>> code significantly easier to understand and maintain in the future. It
>> would certainly not be without its benefits, so calling it a "waste of
>> effort" is unfair.
>
> I disagree.  We've lived with this GC code for a long time, and I
> don't see any complications due to !USE_LSB.  And if we are going to
> switch to igc at some point, investment in GC is even less sensible.
>
> I don't see what's unfair in making my position clear.

I think Pip meant igc. That would be a lot simpler without the 32-bit
stuff, wide ints or not. I said already what I think about that before.

>
>> >> > In fact, one of my strongest reservations about the igc branch is that
>> >> > it will most probably force me to lose WIDE_EMACS_INT.
>> >>
>> >> I believe that problem is exclusively due to the fact that
>> >> WIDE_EMACS_INT implies USE_LSB=0. Dropping !USE_LSB should allow us to
>> >> use WIDE_EMACS_INT normally in MPS builds, I think.
>> >
>> > No, there's also a built-in assumption in MPS about the size of a
>> > word.
>> 
>> That's very vague. If there is an assumption that EMACS_INT ==
>> mps_word_t, it would certainly not be built into MPS, which doesn't know
>> about EMACS_INT at all.
>
> Not EMACS_INT, Lisp_Object.  At least that's what Gerd explained to me
> back when I asked about WIDE_EMACS_INT in the MPS build.  Maybe he can
> chime in and clarify this.

(Not sure I understand the context in which you are discussing.)

As far as igc goes, a Lisp_Object consisting of 2 mps_word_t poses a
problem because we scan one mps_word_t at a time. Depending on where the
tag bits are, we need the other mps_word_t belonging to a Lisp_Object to
be able to determine its type (Lisp_Int0/1Lisp_Symbol, ...). IIRC
this is currently the case, and it's a major PITA.