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. > 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. _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
