Re: pdumper on Solaris 10

[Pip Cet]

"Eli Zaretskii" <eliz@gnu.org> writes:

>> Date: Sun, 08 Dec 2024 13:52:09 +0000
>> From: Pip Cet <pipcet@protonmail.com>
>> Cc: luangruo@yahoo.com, ali_gnu2@emvision.com, emacs-devel@gnu.org
>>
>> "Eli Zaretskii" <eliz@gnu.org> writes:
>>
>> > Which builds except WIDE_EMACS_INT need to use !USE_LSB?
>>
>> The only platforms that "need" to use !USE_LSB are those that cannot
>> guarantee 8-byte alignment for static objects, which is why I asked
>> about those.
>
> That means: none, AFAIK.  At least not given the platforms we
> currently support.  So it's little wonder that configuration had
> bit-rotten.

So let's remove it, and switch WIDE_EMACS_INT builds to USE_LSB?

>> In particular, WIDE_EMACS_INT shouldn't imply !USE_LSB.  That it
>> currently does is a very questionable optimization at best (fixnum
>> manipulation may be very slightly faster with !USE_LSB, but pointer
>> manipulation will be slower and requires extra registers, which is an
>> issue on i386).
>
> Where can one find i386 these days, except in a museum?

I meant all x86 systems using the 32-bit instruction set (and, in
particular, its limited exposed register set).  Those will be around for
a while.

>> (Of course, WIDE_EMACS_INT is almost always a bad deal, anyway.  As far
>> as I can tell, the justification for its continued existence is that
>> some C code assumes buffer positions are fixnums (and, because we expose
>> fixnum-ness to Lisp, some broken Lisp code might do that, too). If we
>> had implemented fixnums to be transparent, we could simply remove
>> WIDE_EMACS_INT, but that mistake has been made...)
>
> I'm a very happy user of WIDE_EMACS_INT, so bad-mouthing it is not
> recommended ;-)

I don't think you should be happy; WIDE_EMACS_INT is sadly necessary to
support buffers > 512MB on 32-bit systems, but you're wasting 32 bits
for almost every Lisp_Object, and registers as well.

As 32-bit systems go away, it will become harder to write Lisp code that
works correctly in !WIDE_EMACS_INT 32-bit builds, so we may well have to
make WIDE_EMACS_INT the default at some point.

> In fact, one of my strongest reservations about the igc branch is that
> it will most probably force me to lose WIDE_EMACS_INT.

I believe that problem is exclusively due to the fact that
WIDE_EMACS_INT implies USE_LSB=0. Dropping !USE_LSB should allow us to
use WIDE_EMACS_INT normally in MPS builds, I think.

(This is somewhat theoretical because I can't build mingw32 Emacs right
now; https://dl.osdn.net alternates between being entirely unreachable
and responding with an expired certificate.)

The "low-hanging fruit" performance improvements USE_LSB allows for
(faster stack scanning during GC and many places which don't need to
look at the MSB word at all) are, I think, real, while the way in which
!USE_LSB is superior (we dereference pointer words without having to
untag them first) may reduce code size slightly, but shouldn't really
affect performance.

Of course, if we set out to do so, 32-bit Emacs could be optimized in
many other ways, but it's too late for that.

Pip