[Vm-dev] [64 bits] Object pointers in jitted code
Eliot Miranda
eliot.miranda at gmail.com
Fri Mar 2 16:28:53 UTC 2018
Hi Guidi,
> On Mar 2, 2018, at 6:44 AM, Guido Chari <charig at gmail.com> wrote:
>
> Hi Eliot,
>
> 2018-02-28 16:03 GMT+01:00 Eliot Miranda <eliot.miranda at gmail.com>:
>>
>> 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
>>
>> > 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)
>>
>> and the generated machine code method will be output to the transcript.
>
> There are plenty of scripts. I ran a few that failed while loading code. Could you point us to the one you are using?
image/buildspurtrunk64vmmaker.sh
image/buildspurtrunkvmmaker.sh
>
>>
>> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20180302/b18e3a2e/attachment-0001.html>
More information about the Vm-dev
mailing list