Re: [Lightning] Re: Proof of concept work on inline functions

[Paulo César Pereira de Andrade]

2010/9/10 Ludovic Courtès <address@hidden>:
> Hi,

  Hi,

  Since Paolo noted the same issue, replying here :-)

>>   In the "work" branch at http://github.com/pcpa/lightning/tree/work
>> I am working on code to convert lightning macros to inline functions,
>> so, any feedback is welcome :-)

  I had already commented about it in a previous email where I said
I was considering to experiment with inline functions, where it would
be probably the most problematic issue with compatibility with existing
code; I noticed this problem before even starting to code :-)

  The concept is being worked in an interactive way, so there is this
issue now, and what I believe would be the solution is to have some
kind of jit_set_state(jit_local_state *_jit) function. And then, the
global variable would be actually a pointer (with a definition somewhat
like the one below).

  Some approach with macros hiding a "this" like pointer as first
argument could also be used, for better implicit source compatibility.
For example:

#define jit_stxi_p(a, b, c) __stxi_p(&_jit, a, b, c)
__jit_inline __stxi_p(jit_state *state, int a, jit_gpr_t b, jit_gpr_t c)
{
...
}

but the &_jit looks wrong, should use a pointer (and lots of s/\./->/
in the source).

> I think it would prevent users from specifying which jit_state to use
> instead of the global one, as in:
>
>  static int
>  generate_foo (jit_state *lightning_state)
>  #define _jit (*lightning_state)
>  {
>    jit_stxi_p (bar, JIT_FP, JIT_RET);
>    ...
>  }
>  #undef _jit

  I believe the benefits the new approach gives could also be
enough of a reason to change it slightly, to something like:

static int
generate_foo(jit_state *lightning_state)
{
    jit_set_state(lightning_state);
    jit_stxi_p(bar, JIT_FP, JIT_RET);
    ...
}

> Thanks,
> Ludo’.

Paulo