emacs-devel
[Top][All Lists]
Advanced

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

Re: Finalizing 'inhibit-automatic-native-compilation'


From: Stefan Monnier
Subject: Re: Finalizing 'inhibit-automatic-native-compilation'
Date: Sat, 28 Jan 2023 13:00:48 -0500
User-agent: Gnus/5.13 (Gnus v5.13)

>> And we do have a solution: pregenerate the trampolines.
> So you are saying that the "prevent writing trampolines" part of
> inhibit-automatic-native-compilation is not needed?

I'm saying it's only needed temporarily, until we fix our compilation
system so trampolines are pregenerated.

>> >> No: what I'm suggesting is to pregenerate the trampolines before we know
>> >> if we'll need them (a bit like `make trampolines`), but to place them
>> >> alongside the code that might need it, so there's no additional "small"
>> >> files containing nothing but a trampoline.  Instead we add tiny chunks
>> >> of code (the trampolines) to other `.eln` files and we do it at a time
>> >> where we know we have GCC at hand.
>> > What do you mean by "alongside"?  The code which needs trampolines is
>> > the code which advises primitives, and that is written in C.  Where
>> > would "alongside" be in that case?
>> 
>> We need trampolines because we call (from .eln files) some functions via
>> 
>>     <functionvar> (...)
>> 
>> instead of looking at the function cell of a symbol, checking what kind
>> of Lisp_Object it holds, etc...
>> 
>> When an advice is installed (i.e. when the function cell of the symbol
>> is modified), we need to update the `functionvar` so it points to
>> a trampoline which does the dance of "looking at the function cell of
>> a symbol, checking what kind of Lisp_Object it holds, etc...".
>> 
>> So, we could pregenerate the trampoline and store it directly inside the
>> subr that's originally stored in the symbol's function cell.
>> So instead of (comp-subr-trampoline-install SUBR) having to generate the
>> trampoline, it would find it in one of the fields of the subr struct.
>
> Thanks, but I don't see how that answers my question.  Unless by
> "inside the subr" you mean we should change the implementation of
> defsubr?  If so, this is definitely not for Emacs 29, and we should
> discuss it separately.  My question about what to do with trampolines
> was about Emacs 29.

I'm definitely talking about a post-Emacs-29 solution here, yes.


        Stefan




reply via email to

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