[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
- Re: pdumper on Solaris 10, (continued)
- Re: pdumper on Solaris 10, Eli Zaretskii, 2024/12/08
- Re: pdumper on Solaris 10, Gerd Möllmann, 2024/12/08
- Re: pdumper on Solaris 10, Eli Zaretskii, 2024/12/08
- Re: pdumper on Solaris 10, Gerd Möllmann, 2024/12/08
- Re: pdumper on Solaris 10, Eli Zaretskii, 2024/12/08
- Re: pdumper on Solaris 10, Gerd Möllmann, 2024/12/08
- Re: pdumper on Solaris 10, Stefan Kangas, 2024/12/08
- Re: pdumper on Solaris 10, Gerd Möllmann, 2024/12/09
- Re: pdumper on Solaris 10, Eli Zaretskii, 2024/12/09
- Re: pdumper on Solaris 10, Po Lu, 2024/12/09
- Re: pdumper on Solaris 10,
Pip Cet <=
- Re: pdumper on Solaris 10, Po Lu, 2024/12/09
- Re: pdumper on Solaris 10, Eli Zaretskii, 2024/12/09
- Re: pdumper on Solaris 10, Po Lu, 2024/12/10
- Re: pdumper on Solaris 10, Pip Cet, 2024/12/11
- Re: pdumper on Solaris 10, Stefan Kangas, 2024/12/08
- Re: pdumper on Solaris 10, Eli Zaretskii, 2024/12/09
- Merging MPS a.k.a. scratch/igc, yet again, Stefan Kangas, 2024/12/09
- Re: Merging MPS a.k.a. scratch/igc, yet again, chad, 2024/12/09
- Re: Merging MPS a.k.a. scratch/igc, yet again, Óscar Fuentes, 2024/12/09
- Re: Merging MPS a.k.a. scratch/igc, yet again, Xiyue Deng, 2024/12/09