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

--
http://BrianTRice.com