just found http://code.google.com/p/libjit-linear-scan-register-allocator/wiki/LLVM_and... 2009/5/7 Igor Stasenko <siguctua@gmail.com>:
2009/5/7 stepken <stepken@web.de>:
Hi!
Connecting Pharo to SUN Lively Morphic GUI:
http://research.sun.com/projects/lively/
has lots of advantages:
  * decoupling of GUI and steering engine in hardware, like X-Server    from X.org   * independance of hardware and OS.   * speed - drawing canvas in SVG is implemented in C, steeting in    JAVA-Script. Google Chrome engine V8 is a ActionScript Jitter    (http://llvm.org/) and even offers OpenGL as C-lib (Khronos) -> No    more plugin's into VM necessary for graphics, same with    vector-font libraries.   * comfort - You can develop your smalltalk software from everywhere,    e.g. pharo vm installed at a webhoster ... or local over loopback    interface.   * Lively and Squeak Morphic mental models fit perfectly, adaption    should be really easy. Dan Ingall being one of the designers of    Lively...   * Pharo's killer applications seaside and pier also are remote    applications, also using ActionScript and browser -> why not for    graphics, morphic and etoys?   * Chrome/FireFox tends to become the standard universal    visualisation and I/O toolkit for all OS, so why not being    lightyears ahead by consequently implementing the GUI in Chrome/FF?
few disadvantages:
  * sound, videostreaming, printing problematic, but easily solvable,    because FF/Chrome already have that features built in ;-)
I'm a bit disappointed by the fact, that the squeak / pharo jitter still has not the expected performance impact. Elliot does a good work, but Frank Lesser with its DNG engine is showing actually, what is technically possible ...C-Speed for Smalltalk and ! Apple is behind LLVM and JAVA 6 is showing also, that C-Speed can be reached in full OO-Languages, see the "language shootout". By the way: ActionScript is a full OO-language, like Smalltalk.
I really wondered, why not LLVM has become the standard jitter in Pharo. Power/ARM/Sparc/Intel ... processors are already supported!
I studied LLVM functionality some time ago. And i don't remember what exactly turns my nose off from it. Maybe because its too C-centric approach: they care much about Globals, Linkage, custom-defined data types, dynamic C code compilation which is totally have no use for smalltalk. I didn't found the ways how i could define own calling convention(s) , other than cdecl. And to make smalltalk contexts efficient, IMO, you have to change it. From what i have seen, in examples like this http://lists.cs.uiuc.edu/pipermail/cfe-dev/2008-August/002670.html  .. LLVM is like a replacement of GCC compiler with mix of useful and not so enhancements (in terms of smalltalk VM needs). Not sure how this could help with making VM which could run smalltalk code - you're still need to write it from scratch.
Mainly, what i would like to reuse from LLVM is native code generator. But again, from what i have seen, the code generator is focused to be a backend for C compiler only. That's only an impression, i could be wrong.
I think, any proprietary Jitter is a design fault ...
just my 2 ct.
Have fun, Guido Stepken
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.