Re: MPS: weak hash tables

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 06 Jul 2024 06:31:14 +0000
> From: Pip Cet <pipcet@protonmail.com>
> Cc: gerd.moellmann@gmail.com, eller.helmut@gmail.com, emacs-devel@gnu.org
> 
> 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.

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.