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

Javier Pimás elpochodelagente at gmail.com
Wed Feb 28 15:36:13 UTC 2018


On Wed, Feb 28, 2018 at 11:13 AM, Clément Bera <bera.clement at gmail.com>
wrote:

>
>
>
> On Wed, Feb 28, 2018 at 2:16 PM, 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). 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. Looking at the slang code
>> I found CogOutOfLineLiteralsX64Compiler, but it seems it is not used
>> (yet?).
>>
>
> Just generate & disassemble any method with literals from the Squeak image
> (in-image compilation workspace scripts) with different ISA and look at the
> disassembled code, it takes 1 second and you'll see by yourself how pointer
> size constants (literals) are dealt with.
>
> The ARM JIT dumps pointer size constants somewhere unreachable by machine
> code execution but near by (in-between jumps for example) and access it
> with PC-relative instructions, that's one good way to work around it.
>

The arm jit also seems to support the two approaches
(CogInLineLiteralsARMCompiler, CogOutOfLineLiteralsARMCompiler), how do you
do gc with inline literals there?


> Best,
>
> Cheers!
>> Pocho
>>
>> --
>> Javier Pimás
>> Ciudad de Buenos Aires
>>
>>
>
>
> --
> Clément Béra
> Pharo consortium engineer
> https://clementbera.wordpress.com/
> Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
>
>


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


More information about the Vm-dev mailing list