<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jun 6, 2015 at 9:33 AM, tim Rowledge <span dir="ltr"><<a href="mailto:tim@rowledge.org" target="_blank">tim@rowledge.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
On 06-06-2015, at 8:15 AM, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>> wrote:<br>
> 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.<br>
<br>
</span>It’s really nice to get to this. There are still some ‘exciting’ parts to get working though… floating point for example.<br>
<span class=""><br>
> 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<br>
<br>
</span>Did this include the FloatMathPluginTests? Because on my Pi2 that segfaults in all versions of the vm - interpreter, stack, cog. Then again my Pi2 is segfaulting on any vm compiled with -O2 right now whereas Eliot’s PiB is just fine with that. Good old GCC strikes again.<br>
<span class=""><br>
> Fun! So I want to revisit the literal load question.<br>
</span><span class="">> In ARMv6T2 and later, MOV can load any 16-bit number, giving a range of 0x0-0xFFFF (0-65535).<br>
> 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.<br>
><br>
</span>Sadly the Pi B/+ are NOT 6T2 cpus. I checked this with Eben a while back. One of the side-effects of the flexibility ARM provides to actual manufacturers is a fairly complex range of possible features within any particular architecture level.<br></blockquote><div><br></div><div>Damn, you're right. gcc with the -march=armv6t2 option will generate 16-bit literal loads, e.g.</div><div><br></div><div>long it() { return 0x1A2B3C4D; }</div><div><br></div><div>=></div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>.arch armv6t2</div><div>...</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>.text</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>.align<span class="Apple-tab-span" style="white-space:pre"> </span>2</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>.global<span class="Apple-tab-span" style="white-space:pre"> </span>it</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>.type<span class="Apple-tab-span" style="white-space:pre"> </span>it, %function</div><div>it:</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>@ args = 0, pretend = 0, frame = 0</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>@ frame_needed = 0, uses_anonymous_args = 0</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>@ link register save eliminated.</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>movw<span class="Apple-tab-span" style="white-space:pre"> </span>r0, #15437</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>movt<span class="Apple-tab-span" style="white-space:pre"> </span>r0, 6699</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>bx<span class="Apple-tab-span" style="white-space:pre"> </span>lr</div><div><br></div><div> </div><br>but compiling, linking and running does indeed signal Illegal instruction. That's /my/ weekend ruined ;-)</div><div class="gmail_quote"><br></div><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">That doesn’t mean we can’t do tricks to make the Pi_2_ use the nice v7 features whilst using out of line data loads on the older machines. In the best case, where the data is already in the cache (we can use PLD to help with that) a LDR takes 2 cycles as opposed to the 4 currently used by our mov/orr^3 unit. Using the v7 MOVT/H is also two instructions but *always* two cycles with possibility of an out-of-cache delay, so I still think it is probably better.<br></blockquote><div><br></div><div>Except that in 64-bits don't we end up with 6 cycles (2 x MOVT/H plus a shift and an add, or maybe 5 cycles if MOVT/H leave other bits undisturbed) vs 2 for the out-of-line literal load? In which case, the out-of-line is a clear win for 64-bits and that's likely our most important target, given the ubiquity of smart phones.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
<br>
tim<br>
--<br>
tim Rowledge; <a href="mailto:tim@rowledge.org">tim@rowledge.org</a>; <a href="http://www.rowledge.org/tim" target="_blank">http://www.rowledge.org/tim</a><br>
</span>Strange OpCodes: EIV: Erase IPL Volume<br>
<br><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div class="gmail_signature">best,<div>Eliot</div></div>
</div></div>