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@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@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
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?
I am interested, but on the somewhat unrelated project Slate (http://slate.tunes.org , long dormant), where we've gotten an SSA instruction set VM working in the last month (http://code.google.com/p/cslatevm/). Our VM is very small and simple, and I have been interested in using LLVM as a back-end for dynamic compilation, but your suggestion about inline C and FFI possibilities is very intriguing as well.
So, I'd like to find out more about how this all works and what I can do to adapt the ideas.
Thanks!
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
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@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@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
squeak-dev@lists.squeakfoundation.org