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 13:52:09 +0000 Message-ID: <87frmyjn9j.fsf@protonmail.com> References: <878qwuitbu.fsf@yahoo.com> <87jzcajrnz.fsf@protonmail.com> <86o71mfhox.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="40287"; 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 15:47:13 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 1tKIYz-000AKd-2u for ged-emacs-devel@m.gmane-mx.org; Sun, 08 Dec 2024 15:47:13 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tKIYA-00042Q-LC; Sun, 08 Dec 2024 09:46:23 -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 1tKHhr-0005ex-Fy for emacs-devel@gnu.org; Sun, 08 Dec 2024 08:52:19 -0500 Original-Received: from mail-10628.protonmail.ch ([79.135.106.28]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tKHhp-0008VZ-6P for emacs-devel@gnu.org; Sun, 08 Dec 2024 08:52:19 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1733665932; x=1733925132; bh=gT1Ho0//+y0Z44pJmWRhzDkaEuTi/HwBfqH7hGcvC4k=; 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=Act9cY7RVcIHd67+5wXyrhCXmWyZt9JEOZ+BdS44BPYlpdJWSAMvmwsA0FA2eVOBq MKCDW2pLx+X7ELtdOmHCjYuxOZJOPkIAhdsjFLiDwBqZiuKbvOGnjeOFrf1JTjx934 ryG07yFk6Zh1drFJ6gX1KQvbjlTWf6wXuwlCTj03A5AopGxG1M6REJd/jZ1djgSPIO TwKBH9kF1OxHlwNRnxUCZ5oezxAl/TQAUmHlFpEPd9Vp0XqxfLuumNLdgVRYkRtB7+ qdMFdVUm2RGuIrgZc6wFttEsEbyRZSMhSFGJGWGagP77kdaWF0w8R4eQhjHzxXVRgN LBR5Xk8JBeusA== In-Reply-To: <86o71mfhox.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 1c6d2e8d4ae4e8f70bf57f851230ac931f734050 Received-SPF: pass client-ip=79.135.106.28; envelope-from=pipcet@protonmail.com; helo=mail-10628.protonmail.ch X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.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, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Sun, 08 Dec 2024 09:46:18 -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:326192 Archived-At: "Eli Zaretskii" writes: >> Date: Sun, 08 Dec 2024 12:17:05 +0000 >> Cc: ali_gnu2@emvision.com, emacs-devel@gnu.org >> From: Pip Cet via "Emacs development discussions." >> >> "Po Lu" writes: >> >> But while we're talking about rare and unusual systems, !USE_LSB builds >> are currently broken except for the WIDE_EMACS_INT case, because the >> stack scanning code makes no attempt to remove MSB tags. > > 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. 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...) Pip