lightning
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Paulo César Pereira de Andrade
Subject: Re: [Lightning] How to call varargs functions from lightning in x86_64?
Date: Fri, 20 Aug 2010 16:46:19 -0300
User-agent: SquirrelMail/1.4.19

Paulo César Pereira de Andrade wrote:

  Hi Paolo,

  I just made some more tests, and corrected known problems in the
patch. I now know it also works with prototyped functions with more
than 8 double arguments (in Linux, that should use the System V abi,
so, should work on Linux and *BSD, unsure about OS/X, and almost
certainly not in Windows), so, with this patch, there should be no
limit in number of integer/float arguments, neither mixing them on
x86_64.

  Leaf functions just work because jit_leaf is an alias to jit_prolog,
but this should also be worked on.

>>   The attached patch pass these tests in my testing tool:
>>
>> http://code.google.com/p/exl/source/browse/trunk/check/lightning/varargs.tst
>
>   Just for the record, the test works correctly in i386, but there
> are some known issues I noticed:
> o there is no need, and it actually is wrong, to modify _jitl.framesize
>   in jit_getarg_*
> o it is missing support for leaf functions (should be trivial to add)
> o #define JIT_FPR(i)  (_XMM8 + (i)) should be _XMM9, and add the
>   proper define.
>
>   Please someone confirm :-), in the meantime, I believe SSEUP probably
> is actually only used for complex double and complex float, so, this
> patch should be very close to a final one.
>
>   The patch is not final, just for considerations, indentation style
> may not match yours, or some of the logic may not match yours also,
> so, no problems in adjusting it.
>
>   I will try to extend the test case soon also to check for passed and
> received parameters of different types, and including some special
> values, i.e. 0x80, 0x8000, etc.
>
>> the test basically does:
>> 1.
>>   o call sprintf with 10 integer arguments
>>   o call sscanf with 10 integer pointer arguments
>>   o check that sscanf reads back what sprintf wrote
>> 2.
>>   o call sprintf with 10 double arguments
>>   o call sscanf with 10 double pointer arguments
>>   o check that sscanf reads back what sprintf wrote
>> 3.
>>   o call a jit function with 10 integer arguments
>>   o the jit function validates the 10 integer arguments
>> 4.
>>   o call a jit function with 10 double arguments
>>   o the jit function validates the 10 double arguments
>> 5.
>>   o call a jit function with mixed long,double,long,double...
>>     totalling 10 longs and 10 doubles
>>   o the jit function validates the arguments
>> 6.
>>   o call sprintf with 10 times the pattern of "%d %f", and pass
>>     10 pairs of longs and doubles
>>   o call sscanf and validate the buffer contents
>>
>>   This works in x86_64, but did not check on i386 yet.
>> Very experimental patch, and probably will only work with varargs
>> functions for > 8 double arguments, as described in the commit message.
>> Still need to check calls to prototyped functions with more than 8
>> double arguments, and, if that changes, that it would be required to
>> have some hint to jit_prepare, what would not be a bad idea at all,
>> as then, it could avoid setting %al for the varargs abi, what it
>> does regardless of calling a varargs or not (but that is minimal
>> overhead)...
>>
>>   Please review/comment.
>>
>>   This has the tricks that should be common to other lightning logic:
>> o must call arg_* for every arguments, in left to right order
>> o must call  getarg_* for every argument, in left to right order
>> o must call jit_prepare before jit_prepare_{f,d} and then may call
>>   jit_prepare_{f,d} any times, but before pushing arguments
>> If not doing the above, it will not work correctly if generating
>> more then one jit function, or nested jit functions.
>
>   Later I will probably ask you again about some kind of bitmap of
> used registers, e.g. no need to save/restore %r13,%r14,%r15, etc if
> not going to use it. The logic should be, tell it is not used,
> otherwise, assume it is used, so it does not affect any existing code,
> or code that does not know about it (unless such code does something
> weird with stack offsets, but then it would be already broken).
>
>   Also, there should be access to the full register set, but by means
> of some kind of "extension". Reasoning is that most times jit should
> not be generated by some "linear code" a programmer wrote, but some
> more complex logic, that should be able to allocate registers, and
> know about side effects. This logic would also want to know JIT_V_NUM,
> JIT_R_NUM, etc. And then, in the case of x86_64, there are 2 new
> "register classes", that are the six integer arguments and eight
> float arguments. Another pseudo class would be special use of the
> temporary for integers (%r11 now in my patch, to not clobber argument
> passed in %r9) and xmm9 (incorrectly set to xmm8 in my initial patch).
>
>   Sorry for writing too much :-)
>
> Paulo

Paulo

Attachment: 0001-Experimental-x86_64-support-for-any-number-of-intege.patch
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]