From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Pip Cet via "Emacs development discussions." Newsgroups: gmane.emacs.devel Subject: Re: pdumper on Solaris 10 Date: Sun, 08 Dec 2024 16:17:53 +0000 Message-ID: <87a5d6jgim.fsf@protonmail.com> References: <878qwuitbu.fsf@yahoo.com> <87jzcajrnz.fsf@protonmail.com> <86o71mfhox.fsf@gnu.org> <87frmyjn9j.fsf@protonmail.com> <86ldwqfcqv.fsf@gnu.org> Reply-To: Pip Cet Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33708"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, ali_gnu2@emvision.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Dec 08 17:34:37 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1tKKEu-0008ZM-Cs for ged-emacs-devel@m.gmane-mx.org; Sun, 08 Dec 2024 17:34:36 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tKKEG-0003hu-SA; Sun, 08 Dec 2024 11:33:56 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tKJyr-0001vg-AK for emacs-devel@gnu.org; Sun, 08 Dec 2024 11:18:01 -0500 Original-Received: from mail-40131.protonmail.ch ([185.70.40.131]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tKJyp-00080d-2K for emacs-devel@gnu.org; Sun, 08 Dec 2024 11:18:01 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1733674676; x=1733933876; bh=LdM2EsRsHiGcV0R/8mXaNWvP7vIe78SYaZMmOqPGdPc=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=ZWidP/FXugQ/dbP0H7bo2L5i82Q4jPSxBzS04veJbl6JN1ez9T6Sj80R1GL5IYI21 2lz/3g9lm2ed6tBv36F5l2Egpce6yxLqiVJCjAnPwozgPmrMxwFVhTROFC/iLDwdtM Cyu/2gdyUnM15D+laVc64QNG7gtrQbjt7JLnTcvpON1ldM7QI/w4TOC7V1o9tLe3bF l62ctMrQRu1wvhxEYMtp5Ov6I+Gl8BIpGRtjvrrROkdlhx4uAwfqP2Zl5CXk3CChVh H2jxhHWY9gSns+WTbNo55q46e8AeklAUH+w2UIMlniH1q8aX9n4VrWqyIkcJwIy0rd Wl/1DiHuKB4gA== In-Reply-To: <86ldwqfcqv.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: d0d36e1d83ee8c66bce1b00319bb31d94fffbfcf Received-SPF: pass client-ip=185.70.40.131; envelope-from=pipcet@protonmail.com; helo=mail-40131.protonmail.ch X-Spam_score_int: -10 X-Spam_score: -1.1 X-Spam_bar: - X-Spam_report: (-1.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Sun, 08 Dec 2024 11:33:53 -0500 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:326196 Archived-At: "Eli Zaretskii" writes: >> Date: Sun, 08 Dec 2024 13:52:09 +0000 >> From: Pip Cet >> Cc: luangruo@yahoo.com, ali_gnu2@emvision.com, emacs-devel@gnu.org >> >> "Eli Zaretskii" 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? >> 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. >> (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. 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. > 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=3D0. Dropping !USE_LSB should allow us to use WIDE_EMACS_INT normally in MPS builds, I think. (This is somewhat theoretical because I can't build mingw32 Emacs right now; https://dl.osdn.net alternates between being entirely unreachable and responding with an expired certificate.) 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. Of course, if we set out to do so, 32-bit Emacs could be optimized in many other ways, but it's too late for that. Pip