Re: [Lightning] How to call varargs functions from lightning in x86_64?

[Paulo César Pereira de Andrade]

Paulo César Pereira de Andrade wrote:

  Hi again,

  Looking a bit at www.x86-64.org/documentation/abi.pdf

[snip]
>   But then, I figured out how to get it to work... Probably this is
> Linux/glibc specific, but setting JIT_R0 (%rax) to the number of float
> arguments, and passing arguments on registers works, at least for
> printf.
>
>   That just required creating a macro for the testing tool, that
> now, instead of 'finish @printf', has a macro like:
>
> #if defined(__x86_64__)
> #  define printf(count)               \
>       movi_ul %r0 count       \
>       finish @printf
> #else
> #  define printf()            \
>       finish @printf
> #endif
>
>
>> It's not insurmountable, but it needs a new form of prepare statement
>> or something like that.
>>
>> Paolo
>
>   Now, the test cases works for both, i386 and x86_64.

  I think it can be implemented significantly better lightning support
for x86_64. It would require setting a flag in jit_prepare() if:

o It will run out of registers, thus, avoiding blindly reading a
  negative offset of the vector lightning/core-64.h:jit_arg_reg_order

o The user specified it is a varargs prepare, like adding a new
  jit_vararg(num) to be used instead of jit_prepare(num). This is the
  only real change to lightning, and should be better than blindly
  setting %rax when it is not required

  And then, use that flag to set %rax when jit_call*/jit_finish* is
called, if required.

  I believe this should be reasonable, of course only support for
basic data types is done, otherwise it would defeat the lightning
purpose as jit, but removing the 6 (+n float) arguments would be
cheap, and not too hard to implement. What do you think?

  BTW, please pardon my ignorance :-), but could it be made cheaper
to "callq routine_address", instead of "movabs routine_address,%r9;
callq *%r9"? I think there should be a reason (not sitting in front
of a x86_64, so cannot test it myself right now...)

  Oh, while at it, since most of the logic would be already in place,
it should not be too hard to also implement jit functions with more
than 6 arguments, or varargs ones in x86_64 :-)

Thanks,
Paulo