Re: pdumper on Solaris 10

[Eli Zaretskii]

> Date: Sun, 08 Dec 2024 17:37:50 +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:
> 
> >> So let's remove it, and switch WIDE_EMACS_INT builds to USE_LSB?
> >
> > That'd be a waste of effort.
> 
> 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'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.
> 
> I think maintainability of the GC code is significant.

It is, but there are no significant issues there at this time due to
!USE_LSB.

> > Those bits are unused in the WIDE_EMACS_INT build, so using them is a
> > no-brainer, IMO.
> 
> As are the low-order bits of pointers, which have the advantage of
> already being present in the 32-bit register rather than needing a
> second register.

What's your point?  The !USE_LSB ode works, the one you suggest needs
to be written and debugged.

> >> >> 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.
> 
> Modern x86 CPUs running 32-bit code (x86, not x32) still need two
> register names for each 64-bit value.  With 8 GPRs, that's a significant
> problem. So, no, "just fine" isn't accurate here.

I again disagree.  And you forget other registers.

> >> > 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.
> 
> 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
back when I asked about WIDE_EMACS_INT in the MPS build.  Maybe he can
chime in and clarify this.

> >> 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.
> 
> If performance and wasted memory aren't issues, then it's a tradeoff
> between leaving old code untouched and simplifying it to enable future
> development.

The existing code doesn't preclude nor interfere with future
development.  So yes, leaving working code untouched is the preference
here.