Re: pdumper on Solaris 10

[Pip Cet via "Emacs development discussions." <emacs-devel@gnu.org>]

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

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

Thanks for the offer.  I definitely think we should move away from
USE_LSB_TAG=0 as much as possible, and if the only place where such a
change would not be vetoed is scratch/igc + WIDE_EMACS_INT, we can at
least fix it there.  If any issues arise, of course, it will be more
difficult to ascertain whether they were caused by the USE_LSB_TAG
change or the IGC changes themselves.

So I'll push that change in a bit, unless someone objects.

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

It does appear to work.  I'm not sure how it is "ugly", to be honest,
since MPS only sees 32-bit words, and that's the tagged pointer and
0. No changes required.

> If it looks like this
>
>   0                 32                   64
>   +------------------+-------------------+
>   |       pointer    |  ...         |tag |
>   +------------------+-------------------+
>
> it gets a lot more ugly. That's USE_LSB_TAG == 0.

Given that gcc likes storing the two 32-bit words of a 64-bit integer in
non-adjacent places on the stack, it would be quite expensive to get
this working.

And if we decided to do that, it would become a lot more complicated to
change our tagging scheme (which we should do, some time after merging
MPS, to speed up EQ by having a "may be EQ to a different object" tag
or, ideally, bit: EQ could then be simplified to

if (x == y)
  return true;
else if (((x|y) & BIT) == 0)
  return false;

<expensive non-inlined code here>)

Pip