[Vm-dev] Stupidifying FFI/library loading mechanism

Denis Kudriashov dionisiydk at gmail.com
Fri May 27 05:11:08 UTC 2011


Thanks for answer.

2011/5/27 Bert Freudenberg <bert at freudenbergs.de>

>
>
> On 26.05.2011, at 20:41, Denis Kudriashov wrote:
>
> Hello
>
> 2011/5/26 Igor Stasenko <siguctua at gmail.com>
>
>>
>> loadInternalModule: moduleName
>> loadExternalModule: moduleName path: pathToModuleLibrary
>>
>> and by analogy, for FFI:
>>
>> loadExternalLibrary: pathToExternalLibrary
>>
>>
> Can you explain what the difference between this kind of module loading.
> Why not enough just loadLibrary: pathToLibrary?
>
>
> VM modules are not just arbitrary libraries. They provide primitive
> Smalltalk methods. They have special entry points like setInterpreter to be
> able to interface with the VM directly. Their location is known to the VM.
> Internal modules are already loaded. But they are still only "activated"
> when one of their primitive is called. They do the name-to-function-address
> mapping on their own rather than using the OS's name resolution mechanism.
>
> Libraries loaded using FFI are just C libraries, nothing special about
> them. The provide C functions. Name lookup is done using OS functions. The
> VM can only guess about their location. Igor was proposing to take the
> guessing out of the VM and put it into the image.
>
>  - Bert -
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20110527/1a692b46/attachment.htm


More information about the Vm-dev mailing list