Re: pdumper on Solaris 10

[Pip Cet]

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

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

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

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

I think most users of 32-bit systems at this stage do care about wasting
a lot of memory, even if you personally don't.

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

I wasn't, and I'm not sure how you got the impression I was. I meant
what I said, that we may have to give up on !WIDE_EMACS_INT 32-bit
builds at some point. As you're using WIDE_EMACS_INT already, this
wouldn't affect you.

>> > 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.  But as it is, I have no idea where you even
suspect this "built-in" assumption is made.

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

Pip