[Vm-dev] Re: ARM Cog progress

[Eliot Miranda]

Hi Ryan, Hi Tim,

On May 21, 2015, at 8:55 AM, Ryan Macnak <rmacnak at gmail.com> wrote:

> On Thu, May 21, 2015 at 5:58 AM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>> 
>> Hi Tim,
>> 
>> On May 21, 2015, at 12:47 AM, timfelgentreff <timfelgentreff at gmail.com> wrote:
>> 
>> >
>> > Does the Pi1 work, too? Or are you using code specific to the newer cpu?
>> 
>>    TimR and I were talking about this yesterday.  The current code generator targets ARMv5, and so works on Pi1.
>> 
>> Pi2 uses ARMv7 which, so TimR tells me, has a 16-bit literal load instruction, which means a 32-bit literal can be generated using two 32-bit instructions.  ARMv5 either requires 4 32-bit instructions, or 1 32-bit instruction to access 1 32-bit literal out-of-line using PC-relative addressing.  I'd like to know what the situation is for ARMv8 (the 64-bit ISA).
>> 
>> The temptation is to move to ARMv7 to get that more compact and faster literal generation.  But it would mean either dropping Pi1 or two VMs.  I'm not afraid of two VMs but it is more stuff, with all the headaches for newbies that entails. Another alternative might be to have the JIT test whether the system is v7 or not and generate the appropriate code, but that is problematic; the JIT will bloat and scanning machine code for object references will slow down.
> 
> Dart puts all object references off into a pool to avoid this.
> 
>> Knowing what ARMv8 does for 64-bit literal synthesis would help me make up my mind.  Whether the JIT should support out-of-line literal load is a somewhat significant issue; it's not something to write unless it's necessary.
> 
> Four 32-bit instructions loading 16-bit pieces, or one pc-relative load.

So out-of-line = 12 bytes vs in-line = 16 bytes.  For me, given that ARM has always supported out-of-line, and it should have good performance, I'd go for out-of-line.  But it's performance could be much worse.  Anyone have any numbers?

Eliot (phone)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20150521/657d1859/attachment.htm