FFI usage

Andreas Raab andreas.raab at gmx.de
Sat May 13 01:51:20 UTC 2006


Alejandro F. Reimondo wrote:
> Thankyou Andreas for the explanation and code.
> I asked for a non-assembly option to compile for PocketPC
>  without learning assembly (to rewrite 20lines of code :-)

You still need to understand the ABI and personally, I typically find 
this harder than learning the basics of the assembler language involved. 
For an unknown ABI I'd actually recommend learning the assembler 
language as a starter, to understand the processor architecture. It 
explains a lot when you read through the ABI and try to understand some 
oddball reference to a register you've never heard about and what its 
purpose might be.

Cheers,
   - Andreas

> thanks again!
> Ale.
> 
> 
> ----- Original Message ----- 
> From: "Andreas Raab" <andreas.raab at gmx.de>
> To: "The general-purpose Squeak developers list"
> <squeak-dev at lists.squeakfoundation.org>
> Sent: Friday, May 12, 2006 7:31 PM
> Subject: FFI usage
> 
> 
>> Alejandro F. Reimondo wrote:
>>> Where can we read details on FFI?
>> Below ;-)
>>
>>> I am interested becasue I feel that the FFI implementation
>>>  requires Assembly code to be compiled.
>>> Is it true?
>> That depends on whether you mean it literally or figuratively. For
>> running the FFI there is a bit of per-platform support code needed, some
>> of which (the actual call-out) is typically implemented directly in
>> machine code and written using assembler.
>>
>>> Is there any "slow" code in slang for platforms that do not have
>>>  easy assemblers?
>> The FFI is (like many other parts of Squeak) "incomplete" in such that
>> it requires a bit of extra support code to implement the actual ABI
>> (e.g., setting up the call stack, calling the function, popping args
>> from the stack etc). This is handled in the platform specific files (see
>> sqWin32FFI.c for an example) and requires some 20 functions or so to
>> work (most of those are trivial but provided just in case some platform
>> has odd behavior wrt. to some data type).
>>
>> It is certainly possible to implement much of it without the use of
>> assembler. For example, if a platform basically passes everything as
>> words (32bit ints) you could do something like here:
>>
>> int args[MAX_ARGS];
>> int argCount;
>>
>> /* take an int as next argument */
>> int ffiPushSignedInt(int value) {
>>    args[argCount++] = value;
>>    return 1;
>> }
>>
>> /* tons of other int types eliminated for brevity here */
>>
>> int ffiPushSingleFloat(double value) {
>>    /* this will push the 32bit equiv. of the float value */
>>    float single = (float) value;
>>    ffiPushSignedInt(*(int*)(&single));
>>    return 1;
>> }
>>
>> /* ... double works just the same way; 2x32bit entity ...*
>> /* ... structures ditto ...*/
>>
>> /* finally, do the actual callout */
>> int ffiCallAddress(int fn) {
>>    switch(argCount) {
>>      case 1: return ((int(*)(int))fn)(args[0]);
>>      case 2: return ((int(*)(int, int))fn)(args[0], args[1]);
>>      case 3: return ((int(*)(int, int))fn)(args[0], args[1], args[2]);
>>      /* ... etc ... */
>> }
>>
>> This will work just fine and requires no assembler but so far I haven't
>> found any platform where things would be as simple as that (both Intel
>> as well as PPC have more complex rules than can be reasonably modeled by
>> this technique). But if you happen to have a platform where things are
>> that simple (or if it's okay to restrict yourself to a subset that can
>> be modeled as simply) that's certainly an option.
>>
>> Cheers,
>>    - Andreas
>>
> 
> 
> 




More information about the Squeak-dev mailing list