emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: MPS native subrs


From: Gerd Möllmann
Subject: Re: MPS native subrs
Date: Wed, 26 Jun 2024 19:12:32 +0200
User-agent: Gnus/5.13 (Gnus v5.13)

Helmut Eller <eller.helmut@gmail.com> writes:

> On Wed, Jun 26 2024, Gerd Möllmann wrote:
>
>>> More generally, it seems that the DEFUN macro works much like the DEFVAR
>>> macro, in the sense that it creates a struct and puts it in a static
>>> variable.  So the Lisp_Subrs structs for primitives are, just like the
>>> Lisp_Fwd structs, already in the data section.  We could re-use them
>>> instead of re-creating them in the dump.  Of course, only if we can get
>>> rid of the command_modes field.
>>
>> And it would again greatly simplify things. Maybe we should just do it :-)
>
> Curiously, igc-info doesn't show any PVEC_SUBRS.  I think this is going on:
>
> The pdumper does something special for primitives and builtin symbols
> (and threads).  Those are dumped to the discardable section.  On load,
> it first performs relocations and then copies everything from the
> discardable section to the data section.  All builtin symbols can be
> copied with a single memcpy to lispsym because they are sorted and
> dumped in the correct order.  The same happens for primitives: those are
> adjacent because the DEFUN macro sets the SUBR_SECTION_ATTRIBUTE.
>
> This explains why igc-info doesn't show any PVEC_SUBRS (unless
> configured with native compilation).  So we already have what we want.
> It's probably no problem that we don't trace the subr section, because
> the command_modes field is nil anyway.

Interesting, thanks!

> I'm not sure why it is done this way; maybe it makes walking the object
> graph more uniform.

Hm.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]