[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Correct byte compiler error/warning positions. The solution!
From: |
Andrea Corallo |
Subject: |
Re: Correct byte compiler error/warning positions. The solution! |
Date: |
Wed, 15 Dec 2021 09:33:45 +0000 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
Alan Mackenzie <acm@muc.de> writes:
> Hello, Andrea.
>
> On Sat, Dec 04, 2021 at 19:22:02 +0000, Andrea Corallo wrote:
>> Alan Mackenzie <acm@muc.de> writes:
>
> [ .... ]
>
>> Hi Alan,
>
>> > For extending emit_EQ, I've got the following embryonic scheme:
>
>> > 1/- Import the C variable symbols_with_pos_enabled:
>
>> > gcc_jit_lvalue *syms_with_pos_enabled =
>> > gcc_jit_context_new_global
>> > (comp.ctxt, NULL,
>> > GCC_JIT_GLOBAL_IMPORTED,
>> > gcc_jit_get_type (comp.ctxt, GCC_JIT_TYPE_BOOL),
>> > "symbols_with_pos_enabled");
>
>> Yep something like. PS We already have 'comp.bool_type' to use.
>
> [ .... ]
>
>> > Can you let me know what you think of this approach, please? That is,
>> > before I put a lot of work into it. Is it broadly a good way of doing
>> > the job?
>
>> I think it could be a good idea but I believe there's no need to use
>> macros here, we could have just functions return rvalues no?
>
> Yes, no macros needed. :-)
>
>> I'm not a big fan of C macros and I try not to use them whem possible.
>
> [ .... ]
>
> I have a problem at the moment, which could be a big problem. How do I
> refer to a Lisp variable from jit generated code?
>
> In particular, I need read-access to symbols-with-pos-enabled, or more
> precisely to globals.f_symbols_with_pos_enabled.
>
> The gcc jit product seems to go out of its way to make such access as
> difficult as possible. There is a way to get an integer out of "C space"
> into the jit mechanism, but this cannot be cast to a pointer type, and
> there is no similar mechanism to get a pointer out of C space. In fact,
> gcc jit seems to restrict the language it supports to the equivalent of
> Pascal, and makes pointer arithmetic impossible.
>
> I tried declaring "globals" as a global variable to be imported into jit
> space, but the loader doesn't know about "globals".
>
> So, how can I get access to globals.f_symbols_with_pos_enabled?
>
> Thanks in advance!
Hi Alan,
I think the way should be done is that one declare in the .eln a global
variable as a (bool *), say 'f_symbols_with_pos_enabled_ref'. Then
during eln load time we set into that the correct address of
'globals.f_symbols_with_pos_enabled' so it can be used as
'*f_symbols_with_pos_enabled_ref' by the generated code.
We do something very similar for the Emacs global var 'current_thread'.
In the eln we have a global variable named "current_thread_reloc" where
we store the address of 'current_thread'. You can see we set this value
during eln load in 'load_comp_unit'.
Just grep CURRENT_THREAD_RELOC_SYM and you should find the relevant
pieces of code you are interested in.
Best Regards
Andrea
- Re: Correct byte compiler error/warning positions. The solution!, (continued)
- Re: Correct byte compiler error/warning positions. The solution!, Alan Mackenzie, 2021/12/02
- Re: Correct byte compiler error/warning positions. The solution!, Andrea Corallo, 2021/12/02
- Re: Correct byte compiler error/warning positions. The solution!, Alan Mackenzie, 2021/12/02
- Re: Correct byte compiler error/warning positions. The solution!, Alan Mackenzie, 2021/12/03
- Re: Correct byte compiler error/warning positions. The solution!, Andrea Corallo, 2021/12/04
- Re: Correct byte compiler error/warning positions. The solution!, Eli Zaretskii, 2021/12/04
- Re: Correct byte compiler error/warning positions. The solution!, Andrea Corallo, 2021/12/04
- Re: Correct byte compiler error/warning positions. The solution!, Eli Zaretskii, 2021/12/04
- Re: Correct byte compiler error/warning positions. The solution!, Andrea Corallo, 2021/12/04
- Re: Correct byte compiler error/warning positions. The solution!, Alan Mackenzie, 2021/12/14
- Re: Correct byte compiler error/warning positions. The solution!,
Andrea Corallo <=
- Re: Correct byte compiler error/warning positions. The solution!, Alan Mackenzie, 2021/12/17
- Re: Correct byte compiler error/warning positions. The solution!, Andrea Corallo, 2021/12/20
- Re: Correct byte compiler error/warning positions. The solution!, Alan Mackenzie, 2021/12/21
Re: Correct byte compiler error/warning positions. The solution!, Andrea Corallo, 2021/12/01