just found http://code.google.com/p/libjit-linear-scan-register-allocator/wiki/LLVM_and_GNU_Lightning
2009/5/7 Igor Stasenko <[email protected]>: > 2009/5/7 stepken <[email protected]>: >> 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 >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
