Hi Eliot, > What's the use case? What do you mean "copy to VM code space"? I > want to know because I want to give you a viable direction, but I > need to know more about your intended use first.
I really appreciate it, but to make it clear: I'm not going to use Cog/Spur VMs for these experiments. By "copy to VM code space" I mean installing a code into the area in which VM keeps machine code. I think you call this "code zone" in Cog. This effectively allows me to generate a code for a method from the "image" itself. Jan > > > > > Thanks! Jan > > > > > > > > On Tue, 2015-12-15 at 18:34 +0100, Clément Bera wrote: > > > We're getting away from Jan initial question here ... > > > > > > I think the point here is that Cog has: > > > - 2 stable back ends: ARMv5 and x86 > > > - 2 backends stable in the simulator with production planned for > > ~ > > > April: x64 and MIPS > > > and Tim is willing to do the ARMv8 backend. > > > > > > All the 4, and soon 5, cog back ends are maintained: > > > - x86 and x64 maintained by Eliot > > > - MIPS maintained by Ryan > > > - ARMv5 and soon ARMv8 maintained by Tim > > > > > > Each backend requires months of work. > > > > > > Do you want to maintain 10 backends instead of 5 ? Do want to > > spend > > > time to implement 5 backends or 10 ? > > > > > > I don't. Only the x86 backend is duplicated right now in AsmJIT. > > > > > > So one idea is to reuse Cog's backends from the image instead of > > > AsmJIT. To do so, we can use encodings available in the sista > > > extended instruction set to tell Cog what machine code to > > generate. A > > > project named uFFI aims, among other things, at doing this, by > > > providing a unified interface between the Cog backends and > > AsmJIT. > > > > > > > > > 2015-12-15 16:43 GMT+01:00 Eliot Miranda <[email protected] > > >: > > > > Hi Jan, > > > > > > > > > On Dec 15, 2015, at 3:06 AM, Jan Vrany <[email protected] > > > > > > > wrote: > > > > > > > > > > Hi guys, > > > > > > > > > > two queations: > > > > > > > > > > (i) Is AsmJit going to be developed any more or it's > > abandoned > > > > > as well as native boost? > > > > > > > > AsmJIT is effectively being abandoned but NativeBoost is not. > > > > > > > > The key limitation of AsmJIT is that it was not designed to be > > > > cross platform; it is effectively an x86 assembler. As such > > it's > > > > use gets in the way of ARM and x86_64 (I am currently getting > > the C > > > > version of 64-bit Cog Spur working on x86_64, given that it is > > > > working in the simulator). > > > > > > > > Another limitation is that it doesn't play that well with the > > VM's > > > > JIT. Igor and I never managed to work on integrating it > > better. > > > > The VM's job is managing code and Igor's approach was to hack; > > > > eliminating execution protection in the entire heap, instead of > > > > extending the support that either the Alien plugin's callback > > > > support or the JIT's executable method zone provides. Making > > the > > > > entire heap executable is /not/ a sensible approach. > > > > > > > > But there is a better way! A key component of the Sista > > adaptive > > > > optimizer/speculative inlined that Clément is currently > > stabilizing > > > > (!!) is a set of bytecodes that encode unsafe operations like > > > > at:put: without bounds, type or store checks. For example, the > > > > normal at:put: is about a hundred instructions, checks for > > > > smallinteger indices, differentiates between byte, 32-but long > > and > > > > pointer objects and does a store check. But one of the Sista > > codes > > > > for at:put: generates about two instructions, one to adjust the > > > > index, the other to do the store. Distaste job is to analyze > > code > > > > and inline methods using these unsafe bytecodes where they are > > > > proven to be safe, hence increasing performance. > > > > > > > > Unlike AsmJIT, Sista's unsafe bytecodes are cross platform, > > and, > > > > being executed by the VM, can work on an interpreter VM or be > > > > converted to machine code by the JIT. > > > > > > > > So our plan is to extend these bytecodes with ones that support > > > > marshaling arguments for NativeBoost calls. Ronie Salgado has > > > > already extended his lowcode scheme to define these > > instructions > > > > and sometime soon (hopefully 2016) we shall rewrite NativeBoost > > to > > > > target these bytecodes. > > > > > > > > HTH > > > > > > > > > (ii)Where can I find latest AsmJit? I'm properly confused: > > > > > > > > > > * Is is the one in latest Pharo 4.0 (5.0) image? > > > > > * Is it the one here: http://smalltalkhub.com/#!/~Pharo/A > > smJi > > > > t ? > > > > > (the one in the image seem to be based on completely > > > > disjunct > > > > > set of .mcz than those in the repo above). > > > > > > > > > > Best, Jan > > > > > > > > _,,,^..^,,,_ (phone) > > > > > > > > > > > -- > _,,,^..^,,,_ > best, Eliot
