[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.
- Re: pdumper on Solaris 10, (continued)
- Re: pdumper on Solaris 10, Pip Cet, 2024/12/09
- Re: pdumper on Solaris 10, Pip Cet, 2024/12/17
- Re: pdumper on Solaris 10, Eli Zaretskii, 2024/12/17
- Re: pdumper on Solaris 10, Po Lu, 2024/12/17
- Re: pdumper on Solaris 10, Pip Cet, 2024/12/18
- Re: pdumper on Solaris 10, Pip Cet, 2024/12/08
- Re: pdumper on Solaris 10, Po Lu, 2024/12/08
- Re: pdumper on Solaris 10,
Po Lu <=
Re: pdumper on Solaris 10, Po Lu, 2024/12/08
Re: pdumper on Solaris 10, Po Lu, 2024/12/08