Re: pdumper on Solaris 10

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

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: Pip Cet <pipcet@protonmail.com>,  luangruo@yahoo.com,
>>   ali_gnu2@emvision.com,  emacs-devel@gnu.org
>> Date: Sun, 08 Dec 2024 20:15:09 +0100
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> 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.
>
> Then it's all a huge misunderstanding, and I apologize fore not
> guessing that it was about igc.  In my defense I can only say that igc
> was never mentioned.

Or I'm wrong, and Pip meant something else.

>> That would be a lot simpler without the 32-bit
>> stuff, wide ints or not. I said already what I think about that before.
>
> If you want to drop the 32-bit stuff, then (a) you will need to find
> someone else to regularly build and test the Windows port of the
> branch, and (b) we will need to agree on emacs-devel right now that
> 32-bit builds of Emacs will be dropped when igc lands.

I would recommend that, indeed, but I don't expect it to happen any time
soon :-).

>> >> > 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. 
>
> That's what I remembered from when you explained that a few months
> ago.

What about dropping, officially sanctioned so to speak, WIDE_EMACS_INT
support for igc? That would help.