emacs-devel
[Top][All Lists]
Advanced

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

Re: pdumper on Solaris 10


From: Gerd Möllmann
Subject: Re: pdumper on Solaris 10
Date: Tue, 10 Dec 2024 19:03:36 +0100
User-agent: Gnus/5.13 (Gnus v5.13)

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Tue, 10 Dec 2024 15:23:45 +0000
>> From: Pip Cet <pipcet@protonmail.com>
>> Cc: Stefan Kangas <stefankangas@gmail.com>, luangruo@yahoo.com, 
>> ali_gnu2@emvision.com, emacs-devel@gnu.org
>>
>> > > I thought that WIDE_EMACS_INT will remain supported in non-MPS
>> > > (i.e. "old GC") builds even after the igc merge? Am I mistaken?
>> >
>> > Probably, but who will want to give up igc to get back WIDE_EMACS_INT
>> > (if indeed they are incompatible, which seems to be in disagreement)?
>>
>> It's !USE_LSB_TAG that's incompatible with MPS, not WIDE_EMACS_INT per se. I 
>> don't think anyone suggested that there is a fundamental problem if we force 
>> USE_LSB_TAG to 1 and enable WIDE_EMACS_INT.
>
> That's not what Gerd says, AFAIU.  But if you are right, then how
> about making the WIDE_EMACS_INT configuration on the igc branch use
> USE_LSB_TAG in the HAVE_MPS code branch?  I can volunteer to test such
> a build, if that would help.

If a Lisp_Object looks like this

  0                 32                   64
  +------------------+-------------------+
  | tag | pointer    |  ...              |
  +------------------+-------------------+

there is a chance it could be made to work, if ugly. That's USE_LSB_TAG
== 1.

If it looks like this

  0                 32                   64
  +------------------+-------------------+
  |       pointer    |  ...         |tag |
  +------------------+-------------------+

it gets a lot more ugly. That's USE_LSB_TAG == 0.



reply via email to

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