I have some interest in this, particularly for integrating with C++  
libraries that others have written.  However, having spent this  
morning reading about LLVM, it appears that there is no silver bullet  
for linking with existing C++ libraries.  This isn't surprising, since  
dealing with name-mangling and other C++ ABI issues isn't LLVM's  
focus.  I have a sliver of hope that you'll tell me I've  
misunderstood, and that LLVM actually can make it easier to link to  
existing libraries.

A clang-based FFI also sounds interesting.  Would it be possible to   
generate an entire FFI "module" by sucking in a header file, rather  
than hand-coding (or writing a Smalltalk source generator for) all of  
the FFI-invoking methods?  Seems like this is within Clang's scope.

Is the source-code for your existing work available anywhere?

Cheers,
Josh


On Oct 16, 2008, at 1:40 AM, Antony Blakey wrote:

> I did some work to integrate LLVM and Clang with VW. I'm moving this  
> to Squeak. For the platforms supported by LLVM this allows inline C/ 
> ObjC/C++ (although C++ is early days yet), dynamically compiled and  
> loaded, and highly optimized platform-independent SSA-based native  
> code generation. As a side effect it can provide an optimized FFI  
> based on jitted stubs/trampolines. I did this (trivially) for  
> callout in VW, but didn't bother about callbacks. You can also use  
> Clang to parse platform headers (and code), which you can obviously  
> include in inline C, and also produce a parse tree with various  
> degrees of semantic analysis, which you can then reflect on. Clang  
> goes to extraordinary lengths to maintain source correspondence,  
> which is an added bonus in interactive environment such as Smalltalk.
>
> Eliot's aware of that work. AFAIK he decided against using LLVM for  
> Cog because Qwak wanted something that didn't increase the VM  
> footprint, although he probably had some other reasons as well. PICs  
> were an issue he raised, but that can be dealt with - in fact, by  
> using runtime type recording at the call sites, plus some techniques  
> used in multi-method dispatch for CLOS, you can optimize for both  
> sides of a double dispatch, which would given at the very least  
> highly optimized numeric operations. LLVM also does cool link time  
> optimization and inlining, and I've got this (largely unformed) idea  
> that the type-based specialisation could possibly trickle back along  
> a call chain, resulting in block-aggregation that would expose more  
> opportunity for optimization by delimiting regions of known type  
> information. It might be however that such regions never practically  
> get above a certain size.
>
> I'd like to investigate using LLVM to make plugins that are  
> dynamically compiled and loaded (i.e. not via VMMaker). A further  
> thought is that the VM could be regenerated, compiled and switched  
> whilst running. This leads obviously to a *very* basic cross- 
> platform headless VM that regenerates itself upon loading, optimized  
> for the platform it's running on. Of course you'd cache this.
>
> Benefits of LLVM/Clang over roll-your-own native code generation are  
> a) the significant optimization systems; b) cross-platform code  
> generation; and c) dynamic C-family integration.
>
> And finally, LLVM/Clang are two of the most beautifully, cleanly  
> architected and written pieces of C++ code I've ever seen. No, I'm  
> not a contributor :)
>
> Anyone else interested in this?
>
> On 16/10/2008, at 6:33 PM, Alexandre Bergel wrote:
>
>> Talking about interoperability. I did some experiment a while ago  
>> about making Squeak talk to Java using sockets. Java classes are  
>> accessible within Squeak, and reflection is used to invoke methods.
>> People interested in this could ask for further info.
>>
>> Cheers,
>> Alexandre
>>
>> On 16 Oct 2008, at 09:55, Lukas Renggli wrote:
>>
>>>> But then, the new FFI of Eliot seems to be far, far better then  
>>>> the old
>>>> one.
>>>> It would be nice to have that instead. E.g, it supports callbacks  
>>>> nicely
>>>> and
>>>> is much faster.
>>>
>>> Go Eliot, go! It is crucial that Smalltalk gets better bindings with
>>> the outside world. It should be easy (as with Python or Ruby) to
>>> integrate some external C library.
>>>
>>> I hope the new FFI doesn't need to hack the Smalltalk language and  
>>> compiler.
>>>
>>> Cheers,
>>> Lukas
>>>
>>> -- 
>>> Lukas Renggli
>>> http://www.lukas-renggli.ch
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> Pharo-project at lists.gforge.inria.fr
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>
>> -- 
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel  http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> Pharo-project at lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> Antony Blakey
> -------------
> CTO, Linkuistics Pty Ltd
> Ph: 0438 840 787
>
> When I hear somebody sigh, 'Life is hard,' I am always tempted to  
> ask, 'Compared to what?'
>  -- Sydney Harris
>
>
>