Re: [Lightning] Feature Request: Allow patching of st(x)i and ld(x)i

[Marc Nieper-Wißkirchen]

Hi Paulo,

Am Di., 3. Sept. 2019 um 22:27 Uhr schrieb Paulo César Pereira de
Andrade <address@hidden>:
>
> Em ter, 3 de set de 2019 às 14:11, Marc Nieper-Wißkirchen
> <address@hidden> escreveu:
>
>   Hi Marc,

[...]

> > It would be a nice addition to GNU lightning if user data could be
> > stored along the code, for which GNU lightning could use IP-relative
> > addressing if available on the target architecture.
>
>   Lightning does not export any interface for something like this.
> There is jit_code_data, but it is used only internally, to create a
> memory buffer for constants, when it is significantly cheaper to
> load from memory.
>
>   Mixing data with code is not a good idea. Need jumps over it,
> and can easily cause it to create expensive branches due to
> needing to jump over data when creating normal jumps, and
> the worst would be adding noise to the processor cache. Still,
> lightning implements it for armv5 when not in thumb mode.

Thanks for looking into it.

I think mixing code and data in the way you describe (and which, I
also think, is not a good idea) is not necessary.

What I am thinking of is a pseudo instruction (returning both a label)
of the form

data p, n, a

Here, P is a (char const *) pointing to some data or NULL, N the size
of the data in bytes, and A a suitable alignment.

When emiiting the jitted code, GNU lightning would then reserve
somewhere (!) sufficient space of N bytes and would fill it (i.e.
memcpy) using the data pointed to by P if any. On jit_destroy (), the
data section is freed as well. As jit_data is supposed to return a
label, it can be used with jit_patch_at so that the code can access
the data.

Note that the data does not have to be (and shouldn't be) embedded in
the middle of the code. It can be stored at the end of the generated
code.

The idea is that GNU lightning can control where the data lies in
relation to the generated code (or knows it a least), so it can use
(on some targets) more efficient IP-relative addressing of the data.

[...]

Best,

Marc