emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: pdumper on Solaris 10


From: Pip Cet
Subject: Re: pdumper on Solaris 10
Date: Mon, 09 Dec 2024 09:56:18 +0000

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

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

I was talking about the non-mps branch, yes.  We should drop !USE_LSB,
which doesn't work in its original use case today and hasn't for a
while.  It does happen to work in the WIDE_EMACS_INT case, but that's a
fortuitous accident at best.

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

(Of course, we have

typedef EMACS_INT Lisp_Word;
typedef Lisp_Word Lisp_Object;

so this is the same thing)

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

So the problem is !USE_LSB, not WIDE_EMACS_INT.  Another reason we
should drop !USE_LSB, since it gives us working WIDE_EMACS_INT + MPS
builds.

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

I don't see a technical reason to do so, since WIDE_EMACS_INT + !USE_LSB
works fine (see the patch I sent).  We already refuse to build igc.c in
!USE_LSB situations and should continue to do so.

Pip




reply via email to

[Prev in Thread] Current Thread [Next in Thread]