[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
- Re: Finalizing 'inhibit-automatic-native-compilation', (continued)
Re: Finalizing 'inhibit-automatic-native-compilation', Eli Zaretskii, 2023/01/28
Re: Finalizing 'inhibit-automatic-native-compilation', Stefan Monnier, 2023/01/27
- Re: Finalizing 'inhibit-automatic-native-compilation', Eli Zaretskii, 2023/01/28
- Re: Finalizing 'inhibit-automatic-native-compilation', Stefan Monnier, 2023/01/28
- Re: Finalizing 'inhibit-automatic-native-compilation', Eli Zaretskii, 2023/01/28
- Re: Finalizing 'inhibit-automatic-native-compilation', Stefan Monnier, 2023/01/28
- Re: Finalizing 'inhibit-automatic-native-compilation', Eli Zaretskii, 2023/01/28
- Re: Finalizing 'inhibit-automatic-native-compilation',
Stefan Monnier <=
- Re: Finalizing 'inhibit-automatic-native-compilation', Eli Zaretskii, 2023/01/28
- Re: Finalizing 'inhibit-automatic-native-compilation', Stefan Monnier, 2023/01/28
- Re: Finalizing 'inhibit-automatic-native-compilation', Eli Zaretskii, 2023/01/29
- Re: Finalizing 'inhibit-automatic-native-compilation', Stefan Monnier, 2023/01/29
- Re: Finalizing 'inhibit-automatic-native-compilation', Eli Zaretskii, 2023/01/29
- Re: Finalizing 'inhibit-automatic-native-compilation', Stefan Monnier, 2023/01/29
- Re: Finalizing 'inhibit-automatic-native-compilation', Eli Zaretskii, 2023/01/30
- Re: Finalizing 'inhibit-automatic-native-compilation', Stefan Monnier, 2023/01/30
- Re: Finalizing 'inhibit-automatic-native-compilation', Eli Zaretskii, 2023/01/30
- Re: Finalizing 'inhibit-automatic-native-compilation', Stefan Monnier, 2023/01/30