From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-il1-x12d.google.com (mail-il1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) by sourceware.org (Postfix) with ESMTPS id 38DF93858D20 for ; Thu, 26 Jan 2023 22:20:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 38DF93858D20 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=sifive.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=sifive.com Received: by mail-il1-x12d.google.com with SMTP id f8so1405773ilj.5 for ; Thu, 26 Jan 2023 14:20:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=yzxtX7Vm9wV19iraX3xx3Ce53M7B0ofiFaSwOCEUSgo=; b=MLoTPPDULtadN06uLsMpDJkkB1HIg07egET4lX9SqdqsV6ni/AytGteKXzm805t28w 5jYFXxFbdmSr6PV5y7Onfsxqu3q/nDxyuj8PBmtPyyizJOulyXt3pl272696AJhOg13v nC4U6oga+rGcF2wj9Cb0E8UltUGT4AZS1jnf1gjWesRx5J9sHkycd5/JMQN5b/inn2ZQ V1vvU8N1exz9nCIzS/D9CigBCMenMi9wZnjgN7KIONcfB9nwOAZ88kn7gxrQS6T26R/a 4WIc7+lwnV06yh1iPP8qqaOE5yfY3C8/khN8SfNpceuqRZlSpfn2zVLje73LBce+Loma UBkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=yzxtX7Vm9wV19iraX3xx3Ce53M7B0ofiFaSwOCEUSgo=; b=L74nWjbC4vhU0bQITYIdojKYDus9mbqpCvs14vauUSjRnQSdKtAdJksTi9XhePhGcw tMs8/mf8bfnEK4lSuz6lNQtuxXsJ/1Jo/LKbGxtiKkr34yCW1vtIyvZ8KAg2cYuCyK5i 9JMNUyiooRh/591DcLW6z/Yz3aNTqiaoW5ByVAvsn4Byo+odqDMWf2cV1QzjRjAzUY3M 1+Yuzzxz8dw8QytPdUmip8pyfalZWp8ZMBRCReb8iMvb9KlMo55auuWzFiE2jiGLz/Hs DZ3mb3tTF+XkAZPy3FiDIRufBKbGxe+zEszfn0EY0ihfiJ308N50FeStJotK9iNdlLek pL+Q== X-Gm-Message-State: AO0yUKX5Mbx6P5l5qwncKZy7GZUfSc9/drsM5QAU7qwXWo3tb+FluZq5 qBFKPnHb2UvpOzIRpU+UTFXpooFywwC1VAnnDNF8nMqQWwbpFMMpTkH6o2L2PGn9kazL75rlpdm +NSOawgkpoAcHk3vUynu3yO5AHn4nFCTTPP+nl4JcG7dRKX1IN93Hm3aWV/hM8yQWiOG6Tws= X-Google-Smtp-Source: AK7set/4Pr6G2staSskq69sk6dcwH+slRbwxdcIp8YAjL6nJ/RUeTa6jjuUJ+XbLanPpJ62QaRBz1A== X-Received: by 2002:a05:6e02:1d8c:b0:310:a935:46ef with SMTP id h12-20020a056e021d8c00b00310a93546efmr6672532ila.3.1674771615866; Thu, 26 Jan 2023 14:20:15 -0800 (PST) Received: from mail-il1-f171.google.com (mail-il1-f171.google.com. [209.85.166.171]) by smtp.gmail.com with ESMTPSA id c44-20020a023f6c000000b003a95a210793sm820465jaf.165.2023.01.26.14.20.15 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 26 Jan 2023 14:20:15 -0800 (PST) Received: by mail-il1-f171.google.com with SMTP id i1so1397700ilu.8 for ; Thu, 26 Jan 2023 14:20:15 -0800 (PST) X-Received: by 2002:a92:a80c:0:b0:310:c254:6cc3 with SMTP id o12-20020a92a80c000000b00310c2546cc3mr195863ilh.14.1674771614827; Thu, 26 Jan 2023 14:20:14 -0800 (PST) MIME-Version: 1.0 References: <678b275f-1930-4a59-dfba-fe21cd548fca@suse.com> <95936261-d824-9128-1be9-ba7dfe12b042@suse.com> <54e213db-3268-e7b5-6f11-09dc14a1a49e@suse.com> <8745742c-bbf4-7d12-73c2-50d2d4d58f22@suse.com> In-Reply-To: <8745742c-bbf4-7d12-73c2-50d2d4d58f22@suse.com> From: Andrew Waterman Date: Thu, 26 Jan 2023 14:20:03 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 1/3] RISC-V: prefer SLT{,U} aliases for SLTI{,U} To: Jan Beulich Cc: Binutils , Palmer Dabbelt , Jim Wilson , Nelson Chu , "Maciej W. Rozycki" Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham 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 Thu, Jan 26, 2023 at 1:35 AM Jan Beulich wrote: > > On 26.01.2023 02:29, Andrew Waterman wrote: > > On Wed, Jan 25, 2023 at 7:22 AM Maciej W. Rozycki wrote: > >> > >> 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. > > > > Precisely specifying the assembly syntax has been a weak spot of the > > RISC-V specs, but the general philosophy has been to encourage the use > > of aliases in situations that are seemingly obvious (e.g. ret vs. jalr > > x0, x1, 0) and to be consistent within a family of instructions (e.g. > > since add is an alias for addi, xor had better be an alias for xori). > > Right, and then along exactly these lines slt{,u} better were aliases of > slti{,u}, with matching preference in disassembly. Hence the patch. > > > On the disassembly side, the philosophy has been that more > > human-readable aliases should be used when appropriate (e.g. ret, not > > jalr x0, x1, 0), unless -Mno-aliases is specified (in which case e.g. > > jalr x0, x1, 0 should be printed). > > > > The right place to document this stuff is here: > > https://github.com/riscv-non-isa/riscv-asm-manual/blob/master/riscv-asm.md > > (I don't own this spec, so I'd recommend reporting problems or feature > > requests on the github issue tracker, rather than replying here). > > Hmm, I'm pretty uncomfortable with discussion of things like that in > forms other than email. You may have noticed this already when I was > pointing out other observations and/or inconsistencies in some of the > spec. Ah, that's fine, of course. I (and others) don't mind filing tickets as a consequence of these email discussions, as long as we know we need to do so. > > Jan