From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gandalf.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) by sourceware.org (Postfix) with ESMTPS id 3E8CA3857836 for ; Mon, 30 May 2022 23:55:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3E8CA3857836 Received: by gandalf.ozlabs.org (Postfix, from userid 1003) id 4LBsjt2KDzz4xZH; Tue, 31 May 2022 09:55:46 +1000 (AEST) Date: Tue, 31 May 2022 09:55:40 +1000 From: Paul Mackerras To: Luke Kenneth Casson Leighton Cc: Peter Bergner , Dmitry Selyutin , Alan Modra , binutils@sourceware.org, Alain Williams Subject: Re: Plugin-based opcode table Message-ID: References: <17f6beb2-db1a-0bec-b022-168373c3921b@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-3.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, JMQ_SPF_NEUTRAL, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2022 23:55:52 -0000 Just to clarify something below... On Sun, May 29, 2022 at 10:13:06AM +0100, Luke Kenneth Casson Leighton wrote: > On Sun, May 29, 2022 at 3:30 AM Peter Bergner wrote: [snip] > > However, the "lxvx" instruction changed between POWER8 (where it was an > > extended mnemonic for lxvd2x) and POWER9 where is became a real instruction > > with a different opcode than lxvd2x (I'm ignoring that doing that was > > a very bad idea!). > > yowser that would have been painful. and a costly mistake that won't go > away for at least another decade [i'm aware that IBM still gets 3rd parties > asking to license POWER8, *for new designs*] > > > How that was solved, was adding PPC_OPCODE_POWER9 > > to the old lxvx instruction's deprecated field to disable that on POWER9 > > and later cpus. POWER9 and later cpus get the new lxvx instruction, > > because we enable it with the PPC_OPCODE_POWER9. > > ok. so this is good to know, because you know what it costs to have to > support a conflicting opcode, long-term. > > now imagine that a binary program needs *both* the old *and* the > new behaviour of lxvx, in the same binary - in public usage. part > of upstream binutils, part of upstream glibc6, and so on. The problem Peter was describing was at the assembly level not the machine code level. The lxvd2x instruction still exists in POWER9 and does the same thing that it does in POWER8. POWER9 added a new instruction which took over the "lxvx" mnemonic. In big-endian mode, lxvx and lxvd2x do the same thing (in little-endian, they differ by a double-word swap). That is, the difference is in what bits you get out of the assembler when you write "lxvx", rather than a binary compatibility difference. Paul.