Article: AMD's Mobile Strategy
By: Seni (seniike.delete@this.hotmail.com), December 21, 2011 11:03 am
Room: Moderated Discussions
Exophase (exophase@gmail.com) on 12/21/11 wrote:
---------------------------
>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
It just seems incredibly shortsighted to assume that executables will never be larger than 4GB. Granted, it'll be a while.
Occasionally, you might run into some oddball case like a computed jump into a 12GB lookup table, each entry of which is a block of code.
There's no reason why machine-generated code would have any particular maximum size, so if RAM and caches are adequate for it, you can expect freakish large programs to become more common over time.
>Just don't code it for something like Atom, that move will take two cycles just to fetch ;)
Expecting good performance on Atom is silly. Not only is it an old and obsolete core design, speed was not even a high priority for it at the time.
---------------------------
>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
It just seems incredibly shortsighted to assume that executables will never be larger than 4GB. Granted, it'll be a while.
Occasionally, you might run into some oddball case like a computed jump into a 12GB lookup table, each entry of which is a block of code.
There's no reason why machine-generated code would have any particular maximum size, so if RAM and caches are adequate for it, you can expect freakish large programs to become more common over time.
>Just don't code it for something like Atom, that move will take two cycles just to fetch ;)
Expecting good performance on Atom is silly. Not only is it an old and obsolete core design, speed was not even a high priority for it at the time.
