Re: MPS: weak hash tables

[Pip Cet <pipcet@protonmail.com>]

On Saturday, July 6th, 2024 at 06:10, Eli Zaretskii <eliz@gnu.org> 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.

Pip