This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [committed, PATCH] Remove Disp16|Disp32 from 64-bit direct branches

>>> On 13.05.15 at 13:35, <> wrote:
> On Tue, May 12, 2015 at 11:18 PM, Jan Beulich <> wrote:
>> What _works_ on Intel processors is secondary here. Fact is that
>> the x86-64 design came from AMD, and hence Intel CPUs doing
>> things differently than AMD's is - be honest - a flaw. The more
> I don't think who came first is relevant here.  What relevant are
> 1. AMD and Intel specs are different.

Very interesting statement. If you want to stick to what Intel
specifies, then look at the "N.S." of the respective CALL/JMP
encodings. The explanation of N.S. specifically says "Using an
address override prefix in 64-bit mode may result in model-
specific execution behavior." I don't think you want the
assembler to behave in model-specific ways.

And again - Intel's treatment is inconsistent (operand size prefix
meaning different things depending on context), while AMD's is

> 2. There is no real usage for AMD spec.

Then you could as well rip out the use of data16 on branches in
32-bit mode. And I'm sure there are a lot more cases of "no real
usage" but still being accepted/supported by the assembler.

> 3. There is a bug report against Intel spec.
>> that by analogy with 32-bit mode, an operand size prefix on
>> branches ought to truncate rIP. Plus (other than my own testing
>> says) you seem to suggest that this isn't even consistent on Intel
>> CPUs, as you specifically say "unconditional" above and you also
>> only changed those.
> Please open a bug report against Jcc and I will look into it.

Why would I? I don't want you to cripple Jcc too, but to restore
previous behavior for JMP and CALL.

>>> I will keep my change in unlessl someone can show a real usage of
>>> 066 jmp/call rel16
>>> on AMD processors.
>> That's the wrong position, you have to show that the change is
>> useful - I certainly can't see why you'd need the operand size

But that bug report is simply invalid when considering AMD CPUs.
Hence it should be rejected as such.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]