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/AsmJit ? > > (the one in the image seem to be based on completely disjunct > > set of .mcz than those in the repo above). > > > > Best, Jan > > _,,,^..^,,,_ (phone) >
