Article: AMD's Mobile Strategy
By: Linus Torvalds (torvalds.delete@this.linux-foundation.org), December 20, 2011 8:03 pm
Room: Moderated Discussions
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), 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.
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
>
>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), 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.
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