From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 39422 invoked by alias); 13 May 2015 13:15:32 -0000 Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org Received: (qmail 39383 invoked by uid 89); 13 May 2015 13:15:31 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-ob0-f173.google.com Received: from mail-ob0-f173.google.com (HELO mail-ob0-f173.google.com) (209.85.214.173) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 13 May 2015 13:15:29 +0000 Received: by obcus9 with SMTP id us9so29150460obc.2 for ; Wed, 13 May 2015 06:15:27 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.202.225.65 with SMTP id y62mr15103239oig.78.1431522927068; Wed, 13 May 2015 06:15:27 -0700 (PDT) Received: by 10.76.54.14 with HTTP; Wed, 13 May 2015 06:15:26 -0700 (PDT) In-Reply-To: <55535F58020000780007A08A@mail.emea.novell.com> References: <20150511212331.GA1838@intel.com> <5551F4E70200007800079575@mail.emea.novell.com> <55520C440200007800079718@mail.emea.novell.com> <555216370200007800079773@mail.emea.novell.com> <5552318402000078000798A8@mail.emea.novell.com> <555233B602000078000798EF@mail.emea.novell.com> <555235930200007800079911@mail.emea.novell.com> <555308DB0200007800079CDA@mail.emea.novell.com> <55535F58020000780007A08A@mail.emea.novell.com> Date: Wed, 13 May 2015 13:15:00 -0000 Message-ID: Subject: Re: [committed, PATCH] Remove Disp16|Disp32 from 64-bit direct branches From: "H.J. Lu" To: Jan Beulich Cc: Binutils , Michael Matz Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-05/txt/msg00116.txt.bz2 On Wed, May 13, 2015 at 5:27 AM, Jan Beulich wrote: >>>> 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. Intel SDM says A relative offset (rel16 or rel32) is generally specified as a label in assembly code. But at the machine code level, it is encoded as a signed, 16- or 32-bit immediate value. This value is added to the value in the EIP(RIP) register. In 64-bit mode the relative offset is always a 32-bit immediate value which is sign extended to 64-bits before it is added to the value in the RIP register for the target calculation. As with absolute offsets, the operand-size attribute determines the size of the target operand (16, 32, or 64 bits). In 64-bit mode the target operand will always be 64- bits because the operand size is forced to 64-bits for near branches.A relative offset (rel16 or rel32) is generally specified as a label in assembly code. But at the machine code level, it is encoded as a signed, 16- or 32-bit immediate value. This value is added to the value in the EIP(RIP) register. In 64-bit mode the relative offset is always a 32-bit immediate value which is sign extended to 64-bits before it is added to the value in the RIP register for the target calculation. As with absolute offsets, the operand-size attribute determines the size of the target operand (16, 32, or 64 bits). In 64-bit mode the target operand will always be 64- bits because the operand size is forced to 64-bits for near branches. It is always 64-bit in 64-bit mode on Intel processors. > And again - Intel's treatment is inconsistent (operand size prefix > meaning different things depending on context), while AMD's is > consistent. This isn't a good situation and I can't find a good compromise. I am open to all suggestions. -- H.J.