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: Tue, 17 Dec 2024 13:12:57 +0000 Message-ID: <87pllqcv2s.fsf@protonmail.com> References: <87jzcajrnz.fsf@protonmail.com> <86o71mfhox.fsf@gnu.org> <87frmyjn9j.fsf@protonmail.com> <86ldwqfcqv.fsf@gnu.org> <87a5d6jgim.fsf@protonmail.com> <86a5d6f7bn.fsf@gnu.org> <871pyijctd.fsf@protonmail.com> <8634iyf257.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="34568"; 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 Tue Dec 17 15:17:26 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 1tNYO6-0008oX-4v for ged-emacs-devel@m.gmane-mx.org; Tue, 17 Dec 2024 15:17:26 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tNYNn-0003JO-O3; Tue, 17 Dec 2024 09:17:07 -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 1tNXO0-0007pM-QN for emacs-devel@gnu.org; Tue, 17 Dec 2024 08:13:16 -0500 Original-Received: from mail-40134.protonmail.ch ([185.70.40.134]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tNXNv-0000a5-Bl; Tue, 17 Dec 2024 08:13:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1734441181; x=1734700381; bh=l/Ru/CVJAOly/P9zd3yREITSX5ccxZnAWtBbzc3jXaE=; 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=qR9z7WhwNfLPjJ/s8Kxxw+npZJ622ZcFmIKqgNWK5ivj4Fy4YDcrLEH9ahpCIPcC2 x24oOs6zDkRfumpm8ULeR5LhlGRsan6IR3wNma1YfoVt4whtrjES6Z13bcUoWzCvof D4V3IRT40BUzkRKeOIqYoJo2vew2rYqBbtvr3IIWZXkU9JdLP5qs3OMDooP0+wxkDj gY8GD4Fdz/rWRpyWNA9h6LzkQu3hbVvw70h5hmF5FeTlYa+RZLkkJVolMFCQQQ69b6 gofCAVBaOtCk7ew16cX+nflialGxKkbhgrSjGsBVjDZCV5DvE7nxQdT24UlnznEH/+ jv6wmGf/v/NSQ== In-Reply-To: <8634iyf257.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 0dbfe8b33f5f032956afe450c1a885f5e59f6d22 Received-SPF: pass client-ip=185.70.40.134; envelope-from=pipcet@protonmail.com; helo=mail-40134.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_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_PASS=-0.001, T_SPF_TEMPERROR=0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Tue, 17 Dec 2024 09:17:06 -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:326596 Archived-At: "Eli Zaretskii" writes: >> > 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. > > I again disagree. And you forget other registers. I think this is a perfect example of why discussions with Eli are so hard. What do you disagree with? Which mysterious "other registers" do you mean? Why do you think I "forget" about them, with the implication that I do not understand the x86 architecture? (Of course I'm not forgetting about other registers: x87 FPU registers (which mishandle NaN bit patterns), MMX registers (which are unusable because FPU might be in use), and XMM registers (which do not support integer comparisons setting flags) are all irrelevant in the context we're discussing. I know you know this, which makes your statement even less appropriate.) As for the actual problem, I've continued working on this, and I believe I've come up with a solution which 1. drops WIDE_EMACS_INT 2. drops !USE_LSB_TAG 3. allows the use of "small bignums" for buffer and string positions 4. makes eq =3D eql for "small bignums", where appropriate 5. adjusts the hash table code to do the same 6. enables us to introduce further "exotic" objects (non-trivial 'eq') 7. speeds up and simplifies EQ by branching on a tag bit rather than a global variable 8. possibly (see below) reduces the fixnum range by one bit (invisible to u= sers) I'll post about it in a separate thread once I've decided on a few minor issues: 1. what to do about native compilation. The native compilation code currently produces incorrect code and obviously it is (or should be) a priority to fix that before touching the code in other ways. 2. whether to avoid using GMP for "small" bignums. It would save some memory. This would require an extra tag which would reduce the fixnum range by one bit. 3. what to do about most-positive-fixnum and most-negative-fixnum. These are the only places that "leak" the size of a fixnum to Lisp in the new code, and it's not clear whether we should return the most positive fixnum that fits into a Lisp_Object or the most positive "small bignum", or maybe always return the 62-bit most-positive-fixnum. Pip