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: MPS: weak hash tables Date: Sat, 06 Jul 2024 10:00:52 +0300 Message-ID: <86jzhz57iz.fsf@gnu.org> References: <_mNcR6ailVKpYHLxgfo_tJlYGeR0AQIzQWluspYYp5_g5pIIKkHLNfFkklQQgOKNiVW8jn8NS3i2dJ7_B2Qyx9v-Dq3MQ9mP8HNL30UWsqY=@protonmail.com> <864j946kbe.fsf@gnu.org> <3hUiHuwpNB-2QtvUKSxx3e3-ZUX_xSI4WMW-BDSuybaKMQ3WTjpI2oVBe4Xato-h8bE-d24VQq9I8tE4x-G1-wyKuBD8cGkwaFggC91ndNM=@protonmail.com> <86wmlz59uk.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23811"; mail-complaints-to="usenet@ciao.gmane.io" Cc: gerd.moellmann@gmail.com, eller.helmut@gmail.com, emacs-devel@gnu.org To: Pip Cet Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jul 06 09:01:40 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 1sPzQR-00060h-M9 for ged-emacs-devel@m.gmane-mx.org; Sat, 06 Jul 2024 09:01:39 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sPzPl-0001F2-Mk; Sat, 06 Jul 2024 03:00:57 -0400 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 1sPzPj-0001D7-MI for emacs-devel@gnu.org; Sat, 06 Jul 2024 03:00:55 -0400 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 1sPzPi-0003C8-HZ; Sat, 06 Jul 2024 03:00:54 -0400 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=UoKBWOLkScl84GWQ2Mib5E2DlKB0V+Pk85usdFu8EiU=; b=EdgT0r39VnXj /opooANLMDUzyUCRdKzDIPgD9Xqq+xguSJh98HB42GU9fmDcnPemt21ET/dI9aAdrMllah3+ICA7r LWLlbZ/fgfZMAmJ9fIYf7n0yFfa45EghUoZRBNcTqQoVq9bV+nN1Qg+edgJMidPksokhFT+5elpjY BWwxi5gjZuUp2j7FNd+jBoqIQ2bUIVpq160j54LM7EHERIHOKKwW6+Cc7RNOX4n+doKhAnUTJuHlG KWs3FtUUd83FK9kV3jvNV782aecRvFS+TXkZK9x5vThlpq6CMyfRUHKH9MH45X3JCTAqS9VHYOaAm Y/IwlLh7+xqKaqNzHQdsIQ==; In-Reply-To: (message from Pip Cet on Sat, 06 Jul 2024 06:31:14 +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:321414 Archived-At: > Date: Sat, 06 Jul 2024 06:31:14 +0000 > From: Pip Cet > Cc: gerd.moellmann@gmail.com, eller.helmut@gmail.com, emacs-devel@gnu.org > > On Saturday, July 6th, 2024 at 06:10, Eli Zaretskii wrote: > > > Date: Fri, 05 Jul 2024 20:35:34 +0000 > > > > > From: Pip Cet pipcet@protonmail.com > > > Cc: gerd.moellmann@gmail.com, eller.helmut@gmail.com, emacs-devel@gnu.org > > > > > > > > At least we've excluded WIDE_EMACS_INT :-) > > > > > Which is a pity, IMNSHO, and a major disappointment for me personally, > > > > > since I'm a happy user of that configuration for many years. > > > > > > Interesting. It's not too hard to fit a 62-bit integer into two 32-bit integers which are not 4-bit aligned, of course. I'm not sure what else would go wrong though :-) > > > > The problem, AFAIU, is the MPS assumption that Lisp objects can fit > > into a "word", which in their parlance means integral data type whose > > width is the same as a pointer's. And that is false in WIDE_EMACS_INT > > builds, because Lisp objects are 64-bit wide, whereas pointers are > > still 32-bit. > > I may be misunderstanding something. When talking about normal (strong) objects, MPS assumes very little about how the actual objects are represented, as long as they can be turned into references for tracing. I don't think that's going to be a problem. When dealing with weak options, the IA-32 problem does mean that pointers need to be aligned and non-pointers need to be non-aligned or 0, so we'd need to mangle big fixnums before storing them in what, to MPS, is two 32-bit words. I don't have a clue what you are saying here, sorry. Too many references to terminology I cannot relate to Emacs: "references for tracing", "weak options". Just by randomly picking keywords from the above, I can tell you that we do make sure pointers are 8-byte aligned in the 32-bit builds (which is not easy, at least on MS-Windows, but we succeed anyway). The way the WIDE_EMACS_INT configuration works, most Lisp objects have their high 30 bits (out of 64) cleared, the only exception being fixnums. Not sure this answers or refutes some of what you wrote. At the time Gerd flatly declined to invest any effort in the WIDE_EMACS_INT build, or even explain what needs to be modified in igc.c and elsewhere to make that work, so my build of 32-bit Emacs doesn't use that, because I don't understand MPS innards well enough to do that on my own in what little time I have to dedicate to this branch. Just building MPS with MinGW (a configuration it doesn't support) in a way that passes its test suite was enough of an effort. I will be much happier if the WIDE_EMACS_INT would be supported on the branch.