From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17581 invoked by alias); 18 May 2015 11:48:48 -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 17571 invoked by uid 89); 18 May 2015 11:48:48 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail.emea.novell.com Received: from mail.emea.novell.com (HELO mail.emea.novell.com) (130.57.118.101) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Mon, 18 May 2015 11:48:47 +0000 Received: from EMEA1-MTA by mail.emea.novell.com with Novell_GroupWise; Mon, 18 May 2015 12:48:44 +0100 Message-Id: <5559EDB9020000780007B0A3@mail.emea.novell.com> Date: Mon, 18 May 2015 11:48:00 -0000 From: "Jan Beulich" To: "H.J. Lu" Cc: "Maciej W. Rozycki" , "Binutils" ,"Michael Matz" Subject: Re: [committed, PATCH] Remove Disp16|Disp32 from 64-bit direct branches References: <20150511212331.GA1838@intel.com> <55520C440200007800079718@mail.emea.novell.com> <5552318402000078000798A8@mail.emea.novell.com> <555233B602000078000798EF@mail.emea.novell.com> <555235930200007800079911@mail.emea.novell.com> <5555B0C2020000780007A5FB@mail.emea.novell.com> <5559AB3F020000780007AE54@mail.emea.novell.com> In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SW-Source: 2015-05/txt/msg00153.txt.bz2 >>> On 18.05.15 at 13:22, wrote: > On Mon, May 18, 2015 at 12:05 AM, Jan Beulich wrote: >>>>> On 15.05.15 at 18:52, wrote: >>> * i386-opc.tbl: Add direct call/jmp with Disp16|Disp32 for AMD64. >>> Mark direct call/jmp without Disp16|Disp32 as Intel64. >> >> I had hoped that you wouldn't add back Disp32 to the AMD case, and >=20 > This is what I checked in. Thanks! >> perhaps also that CpuAMD64 and CpuIntel64 would imply Cpu64 (as >> their names already suggest). >=20 > They are just a bit. Make them to implement Cpu64 means adding more > codes to x86 assembler without any benefit. If you can share with me > what you have in mind, I will see what I can do. Ah, no, I didn't mean the assembler to do more work. Instead I thought that the generator utility could set Cpu64 alongside either of the new ones, thus keeping the opcode table slightly better readable. Jan