Re: pdumper on Solaris 10

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sun, 08 Dec 2024 16:17:53 +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:
> 
> >> 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?

That'd be a waste of effort.  What we have now works, and works well.
I'm not interested in throwing away a lot of hard work which got us to
where we are with WIDE_EMACS_INT, for advantages which I'm not sure
even exist, let alone are significant.

Those bits are unused in the WIDE_EMACS_INT build, so using them is a
no-brainer, IMO.

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

Modern x86 CPUs can handle 64-bit values just fine, thank you.

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

Why should I care?  It isn't like each wasted bit comes with some
monetary fine, does it?

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

If you are trying to convince me to switch to 64-bit development
environment, you are wasting your time.  I have my very good reasons,
and don't plan on doing so any time soon.

And 64-but Windows supports 32-bit code perfectly for my needs.

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

No, there's also a built-in assumption in MPS about the size of a
word.

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

I have no problems with performance that I can report, so I don't
expect anyone to waste time and effort on these optimizations.  We
have enough real problems for the resources we have.