[Vm-dev] RE: To FFI or not to FFI

[Andreas Raab]

On 10/4/2010 11:16 AM, Igor Stasenko wrote:
>
> On 4 October 2010 20:41, Andreas Raab<andreas.raab at gmx.de>  wrote:
>>
>> On 10/3/2010 8:50 AM, Schwab,Wilhelm K wrote:
>>>
>>> In saying that "port the vm and everything just works" you appear to be
>>> ignoring that the plugins have to be ported too.  Whether one tweaks and
>>> debugs(!!) Smalltalk or C, there will be things to port and fix.  I for one
>>> would much rather work out the details of a stubborn platform dependency in
>>> readily changed and debugged Smalltalk than C hidden away in the vm.
>>
>> Which in return assumes you have a functioning FFI to begin with. I've
>> pointed this out before and will do it again: One of the great portability
>> advantages of the Squeak VM is that it can be ported *without* requiring a
>> functioning FFI. All you need is a C compiler. There have been many ports
>> where an FFI was never implemented (Zaurus, PS/2, Android) and likely never
>> will be. The ability to port portions of domain code (sockets, files,
>> graphics) without being stopped by having to implement an FFI *first* is
>> what gets people going quickly.
>>
>
> In contrary, i think a first thing which should be ported is an FFI.

I'm not talking about what "should be ported" - I am talking about the 
ports that actually *did* happen. This is practice, not theory. The 
Android port would not exist if it had required an FFI port to begin 
with (it still does not have an FFI). The Zaurus port would have never 
happened (no concept of shared libraries), the PS/2 port neither.

In practice, there is a *huge* advantage for porting if all you need is 
a C compiler and a bit of knowledge about the underlying OS support.

Cheers,
   - Andreas

> Then other developers, who already know how to use FFI could write
> bindings to platform-specific libraries,
> and can experiment fail&  succeed without depending on
> always-busy-and-always-behind-the-deadlines VM maintainer.
> FFI enabling more agile development. And allows a wider audience to
> take part in development, instead of few people,
> who knows how to build VM and write plugins for it.
> Moving code from FFI to VM plugin is much easier then, since you
> already having things which work, and
> all you should do is to replace FFI with primitives, while layer(s) on
> top of that will remain mostly unchanged.
>
>
>> Cheers,
>>   - Andreas
>>
>>> Where I get worried is with an apparent general desire to do everything in
>>> Smalltalk when a shared library might be/is the answer.
>>>
>>> Bill
>>>
>>>
>>>
>>> Bert Freudenberg bert at freudenbergs.de
>>> Fri Oct 1 14:31:52 UTC 2010
>>> We are not talking about optional add-ons. For that, yes, FFI is the
>>> quick-and-dirty solution, go ahead and have fun wrapping every library on
>>> the planet.
>>>
>>> What I am objecting to is the zealous quest to move core functionality out
>>> of proper plugins to the image, be it using FFI or Alien or any other
>>> generic callout mechanism.
>>>
>>> Being able to take an image and run it anywhere without having to worry
>>> about the platform is a Good Thing. Once John ported the Squeak VM to iOS,
>>> Etoys *just worked*. That's the power our VM abstraction gives us.
>>>
>>> Also, the whole Squeak sandbox security model depends on the VM being able
>>> to prevent code in the image to do damage. There is no way to do that if you
>>> let the image use FFI. Do you want my Etoys project to wipe out your hard
>>> disk? I didn't think so.
>>>
>>> There is another benefit to plugins that encapsulate platform
>>> capabilities: Once the interface has been written, you only need to know C,
>>> not so much Smalltalk, to port it to another platform. If the primitive
>>> interface has been well-designed this is much easier than doing it in
>>> Smalltalk. Plus, it is much simpler to get help from platform experts if
>>> they can see the C code.
>>>
>>>
>>
>
>
>