Hi Esteban, Eliot, Clemont

thanks very much for elaborate answer. I'm aware of all what you said
(well, most :-), but my actual needs are very low and primitive.��

All I need now is something that allows me to turn x86_64 assembly��
into a machine code using a sane Smalltalk API, which I can later copy
to VM code space. Nothing more, nothing less :-) I do not fancy
spending time writing yet-another-x86-assembler hence my interest in��
asmjit.��

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 <eliot.miranda@gmail.com>:
> > Hi Jan,
> >
> > > On Dec 15, 2015, at 3:06 AM, Jan Vrany <jan.vrany@fit.cvut.cz>
> > 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/AsmJi
> > 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)
> >