From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: pdumper on Solaris 10 Date: Tue, 17 Dec 2024 16:16:21 +0200 Message-ID: <865xnio0ne.fsf@gnu.org> 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> <87pllqcv2s.fsf@protonmail.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34046"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, ali_gnu2@emvision.com, emacs-devel@gnu.org To: Pip Cet Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Dec 17 15:17:20 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 1tNYO0-0008hd-8C for ged-emacs-devel@m.gmane-mx.org; Tue, 17 Dec 2024 15:17:20 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tNYN9-0002sA-F0; Tue, 17 Dec 2024 09:16:27 -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 1tNYN7-0002rk-6e for emacs-devel@gnu.org; Tue, 17 Dec 2024 09:16:25 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tNYN6-0002tp-4L; Tue, 17 Dec 2024 09:16:24 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=jT/GKDk9S3O/cYCw/S1XMd5fOuw9qGZn9pZXyjlbYd0=; b=kxJtthk54YGJ aPbitITVohHR2RmxtqsjAHon3+FWxdMC4wpyDym4yOiAmS4PoF0s7aveoIUMTpnQaaRLmI4XLDNrF y+pR457CKn42NCNUl9i7PV28tSJJQVja8UwKJEPj0Dp5PvHF+trzL63WzrI4f4j4HQKS1vXRnAIOc 38oLlwXHl0Vbfd8g0RE3hef/3YzzanhqxJvVl9vc0iu1/SxwGRovl/AAVW8SK/ZTKqFZxZYVlz4HL naRKhrudMc2OZR1ZjbfXwB3ZiphdGMrfD20pjwswMDVZFiZrOlZOoCxIARO71uLr6NqBc7wUyLgAE R8OP26syi2g/uv3adSjJGA==; In-Reply-To: <87pllqcv2s.fsf@protonmail.com> (message from Pip Cet on Tue, 17 Dec 2024 13:12:57 +0000) 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:326595 Archived-At: > Date: Tue, 17 Dec 2024 13:12:57 +0000 > From: Pip Cet > Cc: luangruo@yahoo.com, ali_gnu2@emvision.com, emacs-devel@gnu.org > > "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. You always have an option not to argue. > 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 = 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 users) I don't like this solution, because it again will cause us a lot of code churn for very little gain. How many people use WIDE_EMACS_INT these days? I could be the only one. That code works, and works well enough. Certainly well enough for me, and I have yet to hear complaints from anyone else. And !USE_LSB_TAG was dropped in the igc code, so when we merge that, every platform which uses MPS will not have !USE_LSB_TAG. So what is left is to remove WIDE_EMACS_INT, which we should do in some not too distant future, when its last user (yours truly) retires his 32-bit development environment. (We should announce this prominently and enough time in advance, so that in the unlikely case that there are any other users of that configuration, they will have ample opportunity to try to convince us to delay or rethink.) So my suggestion is that you stop wasting your time on the above, because I'm not interested in considering such significant changes for so little gain. What you did on the igc branch regarding WIDE_EMACS_INT and !USE_LSB_TAG (thanks!) should be enough for us, and let's turn our attention and resources to more promising directions. Thanks.