On 26 April 2010 11:58, Igor Stasenko <[email protected]> wrote: > On 26 April 2010 11:17, Adrian Lienhard <[email protected]> wrote: >> Thanks for the explanation. >> >> It might make sense to contact Bryce [1] since Exupery probably has very >> similar mechanism to execute native methods (I think he is only irregularly >> reading this list). Maybe it makes sense to base Exupery on NativeBoost? >> > You are right , of course there are some synergy. Both projects in one > or another way dealing with native code. > > But if you dig a bit deeper , you'll find some differences. > > 1. > - NativeBoost plugin requires very small changes to existing VMs. > I mentioned only one change: allow a code execution for object memory. > To enable it, it requires changing 2 lines of code in sqWin32Alloc.c file > > -- VirtualAlloc(pageBase, commit, MEM_COMMIT, PAGE_READWRITE) > ++ VirtualAlloc(pageBase, commit, MEM_COMMIT, PAGE_EXECUTE_READWRITE) > > (similar amount of changes required for other platforms). > > A plugin, which is a very small thing (only 2 primitives) can be > shipped as external one. > done! > > - Exupery requires a lot more changes to VM. Its even having own VMMaker. > > 2. > - Exupery allocates and uses a separate memory region for storing a > native code there. > So, it requires and additional efforts to manage this memory. > > - NativeBoost uses an object memory (a CompiledMethods for storing a > native code). > And so, it requres no additional efforts to manage a memory. GC is > your friend :) > > 3. > - (last time i seen) Exupery compiler produces a location-dependent > code. So, if you relocate the native code, you have to alter all call > labels, literals and so on. This adds an additional logic to code, in > order to handle that. Sure it saves some CPU cycles (relative calls is > a bit cheaper), except from cases when you moving the code regularily > ;) > > - NativeBoost is intentionally puts you in costraints that you should > not use/produce a location-dependent code i.e. > all jumps should be relative and local to same routine, all calls > should be absolute. > NativeBoost handles the native code relocation automagically and don't > needs an extra effort. >
4. -(last time i seen) Exupery flushing the native code periodically. Actually its using a memory for native code in a cache-like fashion - NativeBoost flushing the native code only once: at image startup. Or on user request. there can be more differences but i think, i presented enough facts , which explaining why i invented own wheel instead of using existing one. >> Cheers, >> Adrian >> >> [1] Bryce Kampjes <[email protected]> >> >> On Apr 25, 2010, at 23:14 , Igor Stasenko wrote: >> >>> On 26 April 2010 00:06, Igor Stasenko <[email protected]> wrote: >>>> On 25 April 2010 23:45, Adrian Lienhard <[email protected]> wrote: >>>>> Hi Igor, >>>>> >>>>> One question I have is how your work compares to Exupery? >>>>> >>>> >>>> Well, i missing the good Exupery description , on squeak source it says: >>>> A bytecode compiler for Squeak, still an alpha project. It doesn't yet >>>> do anything useful but it can compile most bytecodes. >>>> Or from wiki page: >>>> Exupery is a compiler written in Smalltalk that compiles bytecodes to >>>> machine code. >>>> >>>> So, as you can see, an Exupery aims mainly towards turning a bytecode >>>> into a native code, i.e. towards implementing a JIT. >>>> It is important to understand that NativeBoost project having a bit >>>> orthogonal (or more complementary) aim - to allow you to run an >>>> arbitrary native code and speak directly to hardware, OS etc. >>>> >>> >>> Ohh.. i guess you asked about Moebius project. Sorry. >>> >>> Moebius is much more ambitious project. It is a smalltalk environment >>> , fully implemented in itself, i.e. >>> which requires no VM and minimal glue code to run on target platform. >>> >>> While Exupery, is still using a 'VM' concept which interpreting the >>> methods, while additionally providing facilities to optimize the >>> system speed by jitting some methods. >>> In moebius, all methods are initially contain a native code. There is >>> no interpreter. Sure it can be added later (as for any other language >>> interpreter btw), but that will not change the fact that system can >>> sustain itself and run without a need of having VM. >>> >>>> >>>> >>>>> Adrian >>>>> >>>>> On Apr 25, 2010, at 22:21 , Igor Stasenko wrote: >>>>> >>>>>> On 25 April 2010 23:03, Stéphane Ducasse <[email protected]> >>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> (a)(Smalltalk parser) -> >>>>>>> >>>>>>> could you plug the IRBuilder >>>>>> >>>>>> yes i can! The Moebius parser designed by taking in mind, that it can >>>>>> be used as a backend >>>>>> for any kind of encoding. It recognizing a smalltalk syntax and >>>>>> semantic elements and then passing the messages to encoder. >>>>>> And encoder can be anything. It can encode the parsed data into any >>>>>> kind of AST , its just needs to conform with parser's protocol, >>>>>> but can use arbitrary data structures for building the method's AST. >>>>>> Parser don't have _any_ assumptions, into what form an encoder >>>>>> translating the parsed data. >>>>>> >>>>>> So, for instance, i can implement a syntax highlighting encoder, based >>>>>> on this parser, without a need of having separate parser targeted only >>>>>> for syntax highlighting (like SHParserST80) >>>>>> >>>>>>> >>>>>>>> (b)(Native intermediate instructions >>>>>>>> generator (compiler)) -> (c)(Native code translator) >>>>>>>> -> (d)(AsmJit) >>>>>>>> >>>>>>>> I having a, b and d , but c is still not complete. >>>>>>>> And sure thing, one can use it for own purposes , since Moebius >>>>>>>> implemented purely in smalltalk, >>>>>>>> and works in Squeak/Pharo, so potentially it can be retargeted to >>>>>>>> anything else. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Pharo-project mailing list >>>>>>>>> [email protected] >>>>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Best regards, >>>>>>>> Igor Stasenko AKA sig. >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Pharo-project mailing list >>>>>>>> [email protected] >>>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Pharo-project mailing list >>>>>>> [email protected] >>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Best regards, >>>>>> Igor Stasenko AKA sig. >>>>>> >>>>>> _______________________________________________ >>>>>> Pharo-project mailing list >>>>>> [email protected] >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >> >> >> _______________________________________________ >> 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
