[Vm-dev] Re: ARM Cog progress

Eliot Miranda eliot.miranda at gmail.com
Sat Jun 6 15:15:57 UTC 2015


Hi Doug, Hi Tim,  Hi All,

    so yesterday I finally switched on the Raspberry Pi Doug gave me as an
xmas present, built the Spur ARM Cog VM and ... we definitely have a
working VM.  I was able to update a Spur image from mid February all the
way to tip and run tests.  3751 run, 3628 passes, 24 expected failures, 89
failures, 10 errors, 0 unexpected passes
Fun!  So I want to revisit the literal load question.

Doug got me a Pi 1 B.  cat /proc/cpuinfo reveals
processor : 0
model name : ARMv6-compatible processor rev 7 (v6l)
Features : swp half thumb fastmult vfp edsp java tls
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xb76
CPU revision : 7

Hardware : BCM2708
Revision : 000e
Serial : 00000000fe7b08eb

And the ARM Assembler User Guide
<http://www.keil.com/support/man/docs/armasm/armasm_dom1359731146222.htm> says
(emphasis added)
4.4 Load immediate values using MOV and MVN
The MOV and MVN instructions can write a range of immediate values to a
register.

In ARM state:
MOV can load any 8-bit immediate value, giving a range of 0x0-0xFF (0-255).
It can also rotate these values by any even number.
These values are also available as immediate operands in many data
processing operations, without being loaded in a separate instruction.
MVN can load the bitwise complements of these values. The numerical values
are -(n+1), where n is the value available in MOV.
*In ARMv6T2 and later, MOV can load any 16-bit number, giving a range of
0x0-0xFFFF (0-65535).*
The following table shows the range of 8-bit values that can be loaded in a
single ARM MOV or MVN instruction (for data processing operations). The
value to load must be a multiple of the value shown in the Step column.


So it looks to me that the right approach is to add an ARMv6 subclass to
CogARMInstruction that uses the 16-bit literal load instructions and use
that as our standard 32-bit ARM code generator.  But I'm ignorant as to the
processor versions used in the Raspberry Pi.  Are all RPis ARMv6?  What
exactly is ARMv6T2?  I'm guessing that T2 refers to Thunmb2, is that
correct?  And on the specific question can anyone think of a good reason
/not/ to use the 16-bit literal load approach?

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.
>
> 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.
>
> Eliot (phone)
> >
> > --
> > View this message in context:
> http://forum.world.st/ARM-Cog-progress-tp4827195p4827779.html
> > Sent from the Squeak VM mailing list archive at Nabble.com.
>



-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20150606/6b0b7c78/attachment-0001.htm


More information about the Vm-dev mailing list