emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: pdumper on Solaris 10


From: Po Lu
Subject: Re: pdumper on Solaris 10
Date: Mon, 09 Dec 2024 09:08:34 +0800
User-agent: Gnus/5.13 (Gnus v5.13)

Pip Cet <pipcet@protonmail.com> writes:

> 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.  If those exist, we should have received bug reports
> indicating that !WIDE_EMACS_INT builds don't work on such platforms.
>
> 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).
>
> For example, NILP() would only need to look at a single 32-bit word for
> the WIDE_EMACS_INT + USE_LSB configuration. I strongly suspect that
> effect alone would make WIDE_EMACS_INT + USE_LSB faster than
> WIDE_EMACS_INT + !USE_LSB (of course, the relevant optimization would
> have to be made first).
>
> (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...)

Why is WIDE_EMACS_INT a bad deal?  Its effect is just as you describe:
it enables 32-bit systems to access files larger than the standard
fixnum limit on those systems.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]