[Vm-dev] [64 bits] Object pointers in jitted code

[Javier Pimás]

On Wed, Feb 28, 2018 at 12:03 PM, Eliot Miranda <eliot.miranda at gmail.com>
wrote:

>
> Hi Javier,
>
>
> > On Feb 28, 2018, at 5:16 AM, Javier Pimás <elpochodelagente at gmail.com>
> wrote:
> >
> > Hi! This time I'm investigating how cog jit handles pointers to objects
> in native code. In x86-32 its easier because you have immediates of the
> size of a pointer, but in x64 the immediates are restricted to 32bits (and
> I think less in arm).
>
> That's not quite right.  On x86_64 instructions can load 64-bit constants
> into registers.  What is restricted is loading/storing through a 64-bit
> immediate address.  That can only be done to/from %rax.  So when loading an
> arbitrary register from memory the JIT often generates sequences like:
>
>     xchgq %r15,%rax
>     moveq 123456789AB0,%rax
>     xchgq %r15,%rax
>
>
yes, I meant a solution like this. You also need a scratch register if you
want to push a pointer but it's not a huge problem.


> > So I wonder how people works around that, if using a movabs instruction
> every time you need a pointer or if doing something else. I found a mail in
> the list dated from 2011 (titled "questions about cog internals") where you
> (Eliot) said that pointers were inlined in jit code, but I don't know if
> that's still the case.
>
> Yes.  The easy way to see this is to use in-image compilation.  e.g. in a
> VMMaker.oscog image (scripts to build them being in the image directory)
> run the following with a Transcript open:
>
> StackToRegisterMappingCogit
>     genAndDis: Object>>#printOn: "includes 'a ' and 'an '"
>     options: #(ObjectMemory Spur64BitCoMemoryManager)
>
>
Nice! I'll try it


> and the generated machine code method will be output to the transcript.
>
> > Looking at the slang code I found CogOutOfLineLiteralsX64Compiler, but
> it seems it is not used (yet?).
>
> Yes, we should implement this and see how it compares.  It's not
> particularly compelling in x86_64 because we can load 64-bit immediates
> inline but performance might differ significantly.
>
> > Cheers!
> > Pocho
> >
> > --
> > Javier Pimás
> > Ciudad de Buenos Aires
>



-- 
Javier Pimás
Ciudad de Buenos Aires
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20180228/39ca5e05/attachment.html>