Article: AMD's Mobile Strategy
By: anonymous (no.delete@this.spam.com), December 21, 2011 10:57 pm
Room: Moderated Discussions
>> It just seems incredibly shortsighted to assume that executables will
>> never be larger than 4GB. Granted, it'll be a while.
Am there. Facing them. The pain.
> How exactly would you have proposed handling this? To support 32 or
> 64-bit displacements generally you need another bit in the REX prefix
> that you don't have.
In x86-64's 64-bit mode the near branches default to 64-bit operand size
but use a sign-extended 32-bit displacement. Currently adding a REX.W=1
prefix does nothing. All that's needed is a minor re-definition: with W=1 a
near branch could be followed by a sign-extended 64-bit displacement. :)
Yes, such 64-bit near branches would be long, i.e. impact the decoder. But
at least they would let me branch without trampolines, which are far worse.
>> never be larger than 4GB. Granted, it'll be a while.
Am there. Facing them. The pain.
> How exactly would you have proposed handling this? To support 32 or
> 64-bit displacements generally you need another bit in the REX prefix
> that you don't have.
In x86-64's 64-bit mode the near branches default to 64-bit operand size
but use a sign-extended 32-bit displacement. Currently adding a REX.W=1
prefix does nothing. All that's needed is a minor re-definition: with W=1 a
near branch could be followed by a sign-extended 64-bit displacement. :)
Yes, such 64-bit near branches would be long, i.e. impact the decoder. But
at least they would let me branch without trampolines, which are far worse.