Re: MPS experiment successful

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: emacs-devel@gnu.org
>> Date: Wed, 17 Apr 2024 16:30:42 +0200
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> >> That's all. There is nothing more. And I'm currently undecided how to
>> >> proceed with this.
>> >
>> > The next step would be to push a feature branch into the Emacs Git
>> > repository and let people try the branch on the other supported
>> > platforms.  If the code is not yet mature enough for that, please
>> > suggest how to get from here to there.
>>
>> I think technically it could be done, but there are some things that
>> would need to be done. From the top of my head:
>>
>> - CL packages vs. obarrays (I do have packages but no obarrays)
>> - Handling of pure space
>> - Handling the new JSON stuff, which I don't have in my branch, I think.
>> - ...
>
> The packages code will need to be moved aside, yes.  But for the rest,
> why shouldn't a simple merge do the job?  They seem to be orthogonal,
> by and large.

Could be, one has to try. Obarrays could of course be added.

> What is the issue with handling pure space?

I would have to investigate how pure space works, and how to handle it
with MPS. Noting that is impossible in principle, I think.

>> Will increase memory usage in its current state, part of which could be
>> optimized.
>
> How much larger is the memory footprint?

I don't have numbers, but what I can say is that, ATM, every object is 1
word larger, including conses. I did that to siimplify things, and it
could be changed in principle. I think it described in the Org file I
sent.

>> Some configurations/platform might not be possible to support.
>
> Which ones?

MPS must be supported on a platform, of course. MPS' INSTALL file says

  Platforms
  .........

  The MPS uses a six-character platform code to express a combination of
  operating system, CPU architecture, and compiler toolchain.  Each
  six-character code breaks down into three pairs of characters, like
  this::

      OSARCT

  Where ``OS`` denotes the operating system, ``AR`` the CPU
  architecture, and ``CT`` the compiler toolchain.  Here are the
  platforms that we have regular access to and on which the MPS works
  well:

  ==========   =========   =============   ============  =================
  Platform     OS          Architecture    Compiler      Makefile
  ==========   =========   =============   ============  =================
  ``fri3gc``   FreeBSD     IA-32           GCC           ``fri3gc.gmk``
  ``fri3ll``   FreeBSD     IA-32           Clang         ``fri3ll.gmk``
  ``fri6gc``   FreeBSD     x86-64          GCC           ``fri6gc.gmk``
  ``fri6ll``   FreeBSD     x86-64          Clang         ``fri6ll.gmk``
  ``lia6gc``   Linux       ARM64           GCC           ``lia6gc.gmk``
  ``lia6ll``   Linux       ARM64           Clang         ``lia6ll.gmk``
  ``lii3gc``   Linux       IA-32           GCC           ``lii3gc.gmk``
  ``lii6gc``   Linux       x86-64          GCC           ``lii6gc.gmk``
  ``lii6ll``   Linux       x86-64          Clang         ``lii6ll.gmk``
  ``w3i3mv``   Windows     IA-32           Microsoft C   ``w3i3mv.nmk``
  ``w3i6mv``   Windows     x86-64          Microsoft C   ``w3i6mv.nmk``
  ``xca6ll``   macOS       ARM64           Clang         ``mps.xcodeproj``
  ``xci6ll``   macOS       x86-64          Clang         ``mps.xcodeproj``
  ==========   =========   =============   ============  =================

  Historically, the MPS worked on a much wider variety of platforms, and
  still could: IRIX, OSF/1 (Tru64), Solaris, SunOS, Classic Mac OS;
  MIPS, PowerPC, ALPHA, SPARC v8, SPARC v9; Metrowerks Codewarrior,
  SunPro C, Digital C, EGCS, Pelles C. If you are interested in support
  on any of these platforms or any new platforms, please contact
  Ravenbrook at `mps-questions@ravenbrook.com 
<mailto:mps-questions@ravenbrook.com>`_.

As far as Emacs is is concerned, I don't have a clear picture what all
is currently supported in which combinations. For example, wasn't there
something that made Lisp_Object twice as large as a word? Not sure, but
I think that would make things more difficult.

I'm also currently supporting USE_LSB_TAG only. Could maybe be
supported, but unless someone tries...

And so on.