RE: Intel vs AMD64

[Nakajima, Jun]

Thanks for the clarification.

Yes, "implementation specific" is one of the differences between IA-32e
and AMD64, i.e. that behavior is architecturally defined on AMD64, but
on IA-32e (as I posted): 
  Near branch with 66H prefix:
    As documented in PRM the behavior is implementation specific and
should 
    avoid using 66H prefix on near branches.

Jun
>-----Original Message-----
>From: linux-kernel-owner@xxxxxxxxxxxxxxx [mailto:linux-kernel-
>owner@xxxxxxxxxxxxxxx] On Behalf Of richard.brunner@xxxxxxx
>Sent: Wednesday, February 25, 2004 8:28 PM
>To: linux-kernel@xxxxxxxxxxxxxxx
>Subject: RE: Intel vs AMD64
>
>Not sure about other architectures, but in the
>AMD64 architecture, the 66h and 67h prefixes
>can be applied to the near branch
>instructions and have an *architecturally*
>defined action (rather than implementation-defined
>action) which all AMD64 processors follow. It's all
>described in the AMD64 Architecture Programmer's
>Manuals ...
>
>(http://www.amd.com/us-
>en/Processors/DevelopWithAMD/0,,30_2252_739_7044,00.html)
>
>But, I definitely agree that it is sorta hard to figure
>out what a 64-bit general purpose compiler would
>actually *do* with some of them. However, there are
>embedded/special-purpose scenarios where this might
>be just fine.
>
>For example, for JMP (near):
>
>In 64-bit mode, if the JMP target is specified by a
>displacement in the instruction, the signed displacement is
>added to the rIP (of the following instruction), and the
>result is truncated to 16 or 64 bits depending on operand
>size. [rb: 64-bit is default, 66h forces 16-bit].  The
>signed displacement can be 8 bits, 16 bits, or 32 bits,
>depending on the opcode and the operand size.  [rb: 8-bit
>has its own opcode (EB); for the E9 opcode: 32-bit is
>default and 66h forces 16-bit].
>
>] -Rich ...
>] AMD Fellow
>] richard.brunner at amd com
>
>> -----Original Message-----
>> From: Nakajima, Jun [mailto:jun.nakajima@xxxxxxxxx]
>> Sent: Wednesday, February 25, 2004 5:20 PM
>> To: H. Peter Anvin; Timothy Miller
>> Cc: linux-kernel@xxxxxxxxxxxxxxx
>> Subject: RE: Intel vs AMD x86-64
>>
>> 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/
-
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/