Re: pdumper on Solaris 10

[Eli Zaretskii]

> 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.

> 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.

> >> > 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.