Article: AMD's Mobile Strategy
By: Exophase (exophase.delete@this.gmail.com), December 21, 2011 9:33 am
Room: Moderated Discussions
Seni (seniike@hotmail.com) on 12/21/11 wrote:
---------------------------
>I'll have to double-check that. If true, it's a big letdown.
That's why x86-64 adds RIP displacement. True 64-bit absolute addressing is rarely going to be useful: absolute addresses are by nature going to refer to things that are statically allocated as part of the program's text/data/bss/etc sections. These sections combined aren't usually going to stress 4GB, and thus things won't be that far away from code. The heavy allocations that do stress 4GB address space are more likely to go on the heap.
Likewise I don't think programs will often have individual data structures larger than 4GB and needing displacements into the middle of them.
And I'd feel pretty bad if I really did have to embed
>Strange. It might be common but I doubt it has much impact, as its performance
>would be barely different from the 2-instruction equivalent.
Yeah, there's not a big benefit in terms of decode throughput. I just don't like having to blow a register on it.
This amazingly minor, but I like that in the ISAs with registers fixed at zero I can at least store that, which I find myself doing occasionally. I think ARM64 encodes this as storing 0 as well, rather than storing the stack pointer.
>I really should check these things.
>The 32-bit version exists though, and it would have a 4-instruction ARM equivalent.
3 instructions for ARM64: adrp + load will get any 32-bit PC-relative displacement.
>If you need a separate MOV RAX, imm64 then the x86 version takes 2 instructions
>do the work of 6, which is still pretty compact.
Just don't code it for something like Atom, that move will take two cycles just to fetch ;)
---------------------------
>I'll have to double-check that. If true, it's a big letdown.
That's why x86-64 adds RIP displacement. True 64-bit absolute addressing is rarely going to be useful: absolute addresses are by nature going to refer to things that are statically allocated as part of the program's text/data/bss/etc sections. These sections combined aren't usually going to stress 4GB, and thus things won't be that far away from code. The heavy allocations that do stress 4GB address space are more likely to go on the heap.
Likewise I don't think programs will often have individual data structures larger than 4GB and needing displacements into the middle of them.
And I'd feel pretty bad if I really did have to embed
>Strange. It might be common but I doubt it has much impact, as its performance
>would be barely different from the 2-instruction equivalent.
Yeah, there's not a big benefit in terms of decode throughput. I just don't like having to blow a register on it.
This amazingly minor, but I like that in the ISAs with registers fixed at zero I can at least store that, which I find myself doing occasionally. I think ARM64 encodes this as storing 0 as well, rather than storing the stack pointer.
>I really should check these things.
>The 32-bit version exists though, and it would have a 4-instruction ARM equivalent.
3 instructions for ARM64: adrp + load will get any 32-bit PC-relative displacement.
>If you need a separate MOV RAX, imm64 then the x86 version takes 2 instructions
>do the work of 6, which is still pretty compact.
Just don't code it for something like Atom, that move will take two cycles just to fetch ;)
