<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, May 22, 2018 at 1:04 AM, 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">On 21 May 2018 at 13:57, Bruce Hoult via llvm-dev<br>
<span class=""><<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
> "ADRL produces position-independent code, because the address is calculated<br>
> relative to PC."<br>
><br>
> From this, I'd expect ADRP to simply do Xd <- PC + n*4096, where n is a 20<br>
> bit number, just like AUIPC in RISC-V (also a 20 literal multiplied by 4096)<br>
> or AUIPC in MIPS (16 bits multiplied by 65636 there).<br>
<br>
</span>Afraid not. It really is (PC & ~0xfff) + n * 0x1000. So it does<br>
require 12-bit alignment of any code section.<br></blockquote><div><br></div><div>Wow! My mistake. Knock me down with a leaf.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Now that you mention the MIPS & RISC-V alternatives, I'm not sure why<br>
ARM actually made that choice. It obviously saves you a handful of<br>
transistors but I can't quite believe that's all there is to it.<br></blockquote><div><br></div><div>I'm not quite sure how passing 12 bits through an ALU unchanged uses more transistors than inserting muxes to pass them through for some instructions and replace them with zeros for other instructions :-)</div><div><br></div><div>I find Aarch64 inexplicable. There are some truly brilliant touches such as the bit patterns in immediate operands for logical instructions, or the pass-through/invert/negate/increment in the conditional select instruction, or the bitfield move that can extract/insert/sign extend/truncate. But there are are some things that make me think the designers operated in a complete vacuum, not aware of the brilliant bits in ARM32 or other prior art. This is one of them. The abandonment of mixed 16/32 bit opcodes that took Thumb2 to such dominance is another. MIPS have copied that several times with the recently announced nanoMIPS looking pretty good (and with 16, 32 & 48 bit opcodes designed in). RISC-V was of course designed for optional variable length 16&32 bit (and longer in future) opcodes from almost the beginning. All of these give x86_64-beating code density without the sequential decode nightmares.</div><div><br></div></div></div></div>