Article: AMD's Mobile Strategy
By: gallier2 (gallier2.delete@this.gmx.de), December 21, 2011 6:56 am
Room: Moderated Discussions
Linus Torvalds (torvalds@linux-foundation.org) on 12/20/11 wrote:
---------------------------
>Exophase (exophase@gmail.com) on 12/20/11 wrote:
>>
>>I want to see data on immediate requirements. In typical code immediates will often
>>be used for accessing fields of a struct or object. So for them to be too small
>>the object needs to be too big.
>
>No.
>
>Again, you seem to limit yourself to "all I've ever seen
>are architectures that have limited immediates, so they
>cannot do anything else than structure offsets, so nothing
>else exists".
>
>Every single global variable access is a potential
>immediate.
>
>Now sometimes they are cross-module and you need to look
>them up in a table (you could fix them up as a run-
>time linker thing in the code, but you're better off
>trying to avoid it with shared code),
On SPARC even the call to shared-function has to be resolved the hard way. Either by loading a 64 bit immediate address and call via the register or by an indirect call via a table lookup. So you choose between code bloat or double indirection.
> but any time you use
>a "static" variable in C, you'd likely be better off using
>an immediate rip-relative addressing mode for it.
>
>16-bit offsets aren't enough. 20-24 bit offsets often are,
>although it can cause nasty problems when you end up linking
>big programs and suddenly the code segment is tens of
>megabytes, and 24 bits isn't enough to get to the data
>segment after all.
>
>Now, you can say that using a lot of global variables is a
>bad idea, and I'd even agree most of the time. But it's a
>common thing, and it's the right thing to do for many
>cases.
String literals are the most common case in my experience, granted it's limited on Solaris-SPARC.
>
>The fact that you don't even seem to realize that these are
>all immediates just shows how myopic people get when they
>don't have access to good immediates in the instruction
>set.
>
>>YES, the instruction information is public, I've said so multiple times now, I
>>asked you to please go read it before you make more guesses about it (see infocenter.arm.com
>>and register for silver). I can e-mail it to you if you really won't do that.
>
>Why can't you just make it available publicly?
>
>Sounds like it's not public yet. I don't do agreements
>in order to get documentation.
>
>Linus
---------------------------
>Exophase (exophase@gmail.com) on 12/20/11 wrote:
>>
>>I want to see data on immediate requirements. In typical code immediates will often
>>be used for accessing fields of a struct or object. So for them to be too small
>>the object needs to be too big.
>
>No.
>
>Again, you seem to limit yourself to "all I've ever seen
>are architectures that have limited immediates, so they
>cannot do anything else than structure offsets, so nothing
>else exists".
>
>Every single global variable access is a potential
>immediate.
>
>Now sometimes they are cross-module and you need to look
>them up in a table (you could fix them up as a run-
>time linker thing in the code, but you're better off
>trying to avoid it with shared code),
On SPARC even the call to shared-function has to be resolved the hard way. Either by loading a 64 bit immediate address and call via the register or by an indirect call via a table lookup. So you choose between code bloat or double indirection.
> but any time you use
>a "static" variable in C, you'd likely be better off using
>an immediate rip-relative addressing mode for it.
>
>16-bit offsets aren't enough. 20-24 bit offsets often are,
>although it can cause nasty problems when you end up linking
>big programs and suddenly the code segment is tens of
>megabytes, and 24 bits isn't enough to get to the data
>segment after all.
>
>Now, you can say that using a lot of global variables is a
>bad idea, and I'd even agree most of the time. But it's a
>common thing, and it's the right thing to do for many
>cases.
String literals are the most common case in my experience, granted it's limited on Solaris-SPARC.
>
>The fact that you don't even seem to realize that these are
>all immediates just shows how myopic people get when they
>don't have access to good immediates in the instruction
>set.
>
>>YES, the instruction information is public, I've said so multiple times now, I
>>asked you to please go read it before you make more guesses about it (see infocenter.arm.com
>>and register for silver). I can e-mail it to you if you really won't do that.
>
>Why can't you just make it available publicly?
>
>Sounds like it's not public yet. I don't do agreements
>in order to get documentation.
>
>Linus
