[Vm-dev] FFI: Vararg function how to tell callee how many arguments i passed?

Levente Uzonyi leves at elte.hu
Mon Sep 27 23:00:39 UTC 2010


On Tue, 28 Sep 2010, Igor Stasenko wrote:

>
> On 28 September 2010 00:22, Bert Freudenberg <bert at freudenbergs.de> wrote:
>>
>>
>> On 27.09.2010, at 20:21, Bert Freudenberg wrote:
>>
>> On 27.09.2010, at 19:27, Eliot Miranda wrote:
>>
>>
>> On Mon, Sep 27, 2010 at 2:28 AM, Bert Freudenberg <bert at freudenbergs.de> wrote:
>>>
>>>
>>> On 27.09.2010, at 01:23, Igor Stasenko wrote:
>>>
>>>>
>>>> On 27 September 2010 02:12, Levente Uzonyi <leves at elte.hu> wrote:
>>>>>
>>>>> On Mon, 27 Sep 2010, Igor Stasenko wrote:
>>>>>
>>>>>>
>>>>>> Suppose i want to call printf() using FFI.
>>>>>> But it is a variable argument function. What should do to let it know
>>>>>> how many arguments i passed?
>>>>>
>>>>> I think you don't tell it, it guesses the number of arguments from the first
>>>>> argument. If you pass invalid arguments, something bad will happen. :)
>>>>>
>>>>
>>>> Yeah.. i inspected the assembly (gcc -s) for printf call,
>>>> and there is only pushes of arguments , no extra info.
>>>
>>> Vararg functions are specially compiled. They do not use the regular platform calling conventions. That's because the same compiled function needs to be able to take any type of argument. Whereas e.g. floats are normally passed on the float stack, in a vararg function call they might be passed on the regular stack. Also they are converted to doubles at the calling side, just as chars and shorts are promoted to ints.
>>>
>>> So at the calling site the compiler has to do special magic to construct the argument list. It can only do this if you actually provide a vararg call. That is, you need to literally write a printf() call to make this work. There is no portable way around this - the C FAQ states (*)
>>>
>>> Q: How can I call a function with an argument list built up at run time?
>>> A: There is no guaranteed or portable way to do this.
>>>
>>> Squeak's FFI does not support vararg functions yet. There are other FFIs that do (CLISP's vacall library, Rubinius FFI), so taking a look there might help if anyone wants to implement this.
>>
>> While the image-level facilities may not exist the VM provides primitiveCalloutWithArgs which implements ExternalFunction>>invokeWithArguments: and that could be used to do varargs calls.  One has to synthesize the ExternalFunction because the primitive still needs a type vector for the arguments.   But I think it could do the job.
>>
>> No it can't. Maybe re-read what I wrote when you have a little more time ;)
>>
>> Retract that.
>> A little off-line conversation with Eliot convinced me that the parameter passing isn't actually that much different between regular and varagrs calls (if at all). The FFI already does all the non-portable ABI-dependent trickery needed to set up the call. So this might in fact just work :)
>> Anyone up for trying?
>
> Well, i made a callout to printf() via NativeBoost in Linux,
> but was unable to determine if it works, because when i run it, it
> prints nothing on console.
> Probably because stdout is closed by default and i need to reopen it first.

You can always use fprintf :). A few years ago I wrote an incomplete API 
for stdio on windows which worked like this:

fprintf := ExternalLibraryFunction
 	name: 'fprintf'
 	module: 'msvcrt.dll'
 	callType: ExternalFunction callTypeCDecl
 	returnType: ExternalType signedLong
 	argumentTypes: {
 		(ExternalType structTypeNamed: #FILE) asPointerType.
 		ExternalType string.
 		ExternalType signedLong }.
file := Stdio default fopenWith: 'test.txt' with: 'w'.
fprintf invokeWith: file with: 'Your number is %d.' with: 42.
Stdio default fcloseWith: file.

I didn't bother writing a parser which extracts the type information 
from the format string, but if that's done it's pretty easy to do the 
rest. Caching the functions probably improves the performance a lot. I can 
imagine two caches (for *printf functions):
- a larger cache which has typeInfo -> externalFunction mapping
- a smaller cache which maps formatString -> typeInfo

The problem with this method is that FILE structure is platform specific.


Levente


>
>> - Bert -
>>
>
> -- 
> Best regards,
> Igor Stasenko AKA sig.
>


More information about the Vm-dev mailing list