RE: Intel vs AMD x86-64

[Nakajima, Jun]

Yes, that's the very reason I said "useless for compilers." The way
IP/RIP is updated is different (and implementation specific) on those
processors if 66H is used with a near branch. For example, RIP may be
zero-extended to 64 bits (from IP), as you observed before.

Jun
>-----Original Message-----
>From: H. Peter Anvin [mailto:hpa@xxxxxxxxx]
>Sent: Wednesday, February 25, 2004 4:14 PM
>To: Timothy Miller
>Cc: Nakajima, Jun; linux-kernel@xxxxxxxxxxxxxxx
>Subject: Re: Intel vs AMD x86-64
>
>Timothy Miller wrote:
>>
>>
>> Nakajima, Jun wrote:
>>
>>> For near branches (CALL, RET, JCC, JCXZ, JMP, etc.), the operand
size is
>>> forced to 64 bits on both processors in 64-bit mode, basically
meaning
>>> RIP is updated.
>>>
>>> Compilers would typically use a JMP short for "intraprocedural
jumps",
>>> which requires just an 8-bit displacement relative to RIP.
>>
>> I see.  It's too bad you can't have a 16-bit displacement.
>>
>> Ummm... so if 66H were used with a near branch, would that affect the
>> size of the immediate operand which gets added to RIP, or would that
>> affect the the portion of IP/EIP/RIP affected?  If it's the latter,
>> that's pretty silly.
>>
>
>Yes, that would be pretty silly.
>
>I honestly don't remember off the top of my head what "o16 jmp blah"
>does on i386; I have a vague memory that it zero-extends %eip to 32
>bits, which makes it useless, of course.
>
>	-hpa

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/