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

[Jan Beulich]

>>> On 13.05.15 at 13:35, <hjl.tools@gmail.com> wrote:
> On Tue, May 12, 2015 at 11:18 PM, Jan Beulich <JBeulich@suse.com> 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
consistent.

> 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
> 
> https://sourceware.org/bugzilla/show_bug.cgi?id=18386 

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

Jan