[squeak-dev] Re: [Pharo-project] One click feature list
water at tunes.org
Thu Oct 16 21:34:40 UTC 2008
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.
> 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.
>> 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
>>>> It would be nice to have that instead. E.g, it supports callbacks
>>>> 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
More information about the Squeak-dev