From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from angie.orcam.me.uk (angie.orcam.me.uk [IPv6:2001:4190:8020::34]) by sourceware.org (Postfix) with ESMTP id CBD9D3858D28 for ; Wed, 25 Jan 2023 15:22:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CBD9D3858D28 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=orcam.me.uk Authentication-Results: sourceware.org; spf=none smtp.mailfrom=orcam.me.uk Received: by angie.orcam.me.uk (Postfix, from userid 500) id E9F8292009C; Wed, 25 Jan 2023 16:22:40 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by angie.orcam.me.uk (Postfix) with ESMTP id E2DA392009B; Wed, 25 Jan 2023 15:22:40 +0000 (GMT) Date: Wed, 25 Jan 2023 15:22:40 +0000 (GMT) From: "Maciej W. Rozycki" To: Jan Beulich cc: Binutils , Palmer Dabbelt , Andrew Waterman , Jim Wilson , Nelson Chu Subject: Re: [PATCH 1/3] RISC-V: prefer SLT{,U} aliases for SLTI{,U} In-Reply-To: <54e213db-3268-e7b5-6f11-09dc14a1a49e@suse.com> Message-ID: References: <678b275f-1930-4a59-dfba-fe21cd548fca@suse.com> <95936261-d824-9128-1be9-ba7dfe12b042@suse.com> <54e213db-3268-e7b5-6f11-09dc14a1a49e@suse.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-3488.9 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_INFOUSMEBIZ,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Wed, 25 Jan 2023, Jan Beulich wrote: > > This is however what these instructions have been named in the ISA and > > the assembly dialect. In the case of NOP, MOVE, etc. mnemonics they are > > significant assembly idioms (usually mentioned in the ISA manual) and > > there are sometimes thousands of alternative encodings that could be used > > to effect the same operation, but only the chosen canonical encoding is > > disassembled this way. > > Aren't you changing topics? Being able to use alternative encodings to > achieve the same effect isn't what we were talking about. No, it just gives you background as to why some encodings are given canonical aliases (used for disassembly) and why some are not. > > It's rather how the assembly language has been designed (FWIW the RISC-V > > ISA and assembly dialect have been largely inspired by the MIPS approach). > > Well, such a design imo ought to include a clear statement on uses of > aliases. Iirc at least the 32-bit Arm ARM is very precise about what > aliases exist, and it effectively mandates for at least some of them > that they should be use in disassembly. > > As said before, I'd be happy to see things move in about any direction, > just as long as the result is consistent and hence observable behavior > is predictable for users of the assembler and disassembler. It's been consistent so far AFAICT for the RISC-V assembly dialect (and for that matter for the MIPS one as well). If you disagree, then you're welcome to present your view, but I think the context of libopcodes and the binutils mailing list is not the correct place to discuss the assembly language syntax. You'd need to take it to the RISC-V ISA maintainters and then we can implement whatever they've agreed to. Maciej