On Tue, Dec 15, 2015 at 1:55 PM, Jan Vrany <[email protected]> wrote:
> 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. > OK, then you'll want to use the simulator to develop and test a suitable primitive. Right now that means using Squeak 5/Spur or Squeak 4.x/Cog to run the VMMaker image. See http://www.squeakvm.org/svn/squeak/branches/Cog/image and http://www.mirandabanda.org/cogblog/build-image for information on how best to build a VMMaker.oscog image. You'll need to understand a /lot/ of details about how the JIT embeds metadata in the VM. Personally I think you'll get further by providing an interface to the Cogit's assembler API so that, for example, the image-level code doesn't have to mimic all the abort/prolog/frame build code in a method and/or the metadata, but instead says to the Cogit :create me a method with standard prolog, and standard metadata for the following sequence of instructions". And do you think you'll want to embed blocks in your generated code? Also (I can see you're being cagey about the experiments, but that's your choice) I think you'll find life much easier if you eschew generating machine code directly and instead extend the inline primitive byte code used to encode Sista's unsafe operations, and there-by generate the machine code you want using "normal" byte codes. This would be great for us, because you'd be extending the VM with instructions we can all use, and great for you, because you're going to have to do far less work in getting your experiments to work, and your experiment will automatically be cross-platform. > > 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 > > -- _,,,^..^,,,_ best, Eliot
