[lkml]   [2004]   [Feb]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRE: Intel vs AMD64
    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
    avoid using 66H prefix on near branches.

    >-----Original Message-----
    >From: [mailto:linux-kernel-
    >] On Behalf Of
    >Sent: Wednesday, February 25, 2004 8:28 PM
    >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 ...
    >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 []
    >> Sent: Wednesday, February 25, 2004 5:20 PM
    >> To: H. Peter Anvin; Timothy Miller
    >> Cc:
    >> 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 []
    >> >Sent: Wednesday, February 25, 2004 4:14 PM
    >> >To: Timothy Miller
    >> >Cc: Nakajima, Jun;
    >> >Subject: Re: Intel vs AMD x86-64
    >> >
    >> >Timothy Miller wrote:
    >> >>
    >> >>
    >> >> Nakajima, Jun wrote:
    >> >>
    >> >>> For near branches (CALL, RET, JCC, JCXZ, JMP, etc.), the operand
    >> >>> forced to 64 bits on both processors in 64-bit mode, basically
    >> >>> RIP is updated.
    >> >>>
    >> >>> Compilers would typically use a JMP short for "intraprocedural
    >> >>> 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
    >> >> size of the immediate operand which gets added to RIP, or would
    >> >> affect the the portion of IP/EIP/RIP affected? If it's the
    >> >> 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"
    >the body of a message to
    >More majordomo info at
    >Please read the FAQ at
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:01    [W:0.028 / U:10.132 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site