Yep, agreed. I'd forgotten about the older MOVimm, which is stupid because David even mentioned it earlier in the thread.<div><br></div><div>Brain-fail.</div><div><br></div><div>Cheers,</div><div><br></div><div>James<br>
<br><div class="gmail_quote">On 5 June 2013 13:35, Tim Northover <span dir="ltr"><<a href="mailto:t.p.northover@gmail.com" target="_blank">t.p.northover@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">> The architecture in the test case provided was armv4t, which does not have<br>
> MOVW/MOVT.<br>
<br>
</div>It should have the older "MOV (imm)" instructions though, shouldn't<br>
it? They seem to support 8-bits in both ARM and Thumb.<br>
<br>
I'm not even that sure 8-bit loads *should* be supported. We're<br>
unlikely to allocate entries on an 8-bit granularity which means we<br>
can set the rest of the pool entry so that "ldr r0,[wherever]" would<br>
be just as effective and probably no more expensive than the ldrb.<br>
<br>
Not that I think it would be a bad thing necessarily, just probably pointless.<br>
<br>
Cheers.<br>
<span class="HOEnZb"><font color="#888888"><br>
Tim<br>
</font></span></blockquote></div><br></div>