From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) by sourceware.org (Postfix) with ESMTPS id 03C7B3858D38 for ; Thu, 26 Jan 2023 01:29:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 03C7B3858D38 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-io1-xd31.google.com with SMTP id z194so95201iof.10 for ; Wed, 25 Jan 2023 17:29:13 -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=EUcoOS48N+YhYbCLJdYD8Rq/Eb9Ia5nugHfKJp+YfDw=; b=Qzj+W629ig4xJunCCqDa2Tn1NYaW0KTDsmfN+sZY2f7Y2m/jQPGNfGkU85uXV8U2uR pS/cIaIsr8qCBFVJuaIcn6TShrafCmQFlUowFE/y1xs69dNIrsT8USdeDpnCB6gZr4Xk /MN4i3qNR95kIUkBMNvHj4+zbVvF9GQI8QqtsVBO8lshNaGO8zy6ps0KwGc36azUIyNP h6hMfFNPKcrda9B3k/rgtmSY8VV07rpLrXeKxT5PeLQMet5ZIhTGBZcN9K81g/A8iDDT fGFhrqIgwYR3EH4Z2Fk8upHAS4oWUh3eAcqZlRoA541CrWDxFRupBq3tD2E3cg3mWKu6 sFoQ== 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=EUcoOS48N+YhYbCLJdYD8Rq/Eb9Ia5nugHfKJp+YfDw=; b=lyhT35j2IJDa4EGhBjL8y0YaPFHp5fBgywtlLwuPpmlG0BSQrX/VnVyzGmuelWUY+K HwuDuicuPrtDQy4spekCXlSMGQhFPmlIT8rvGBu2C+OiG8y6nAahwPv2uBsFYEsAeYPm /AZcnJhAaEwBUwaVCq32kUUEhWowcMdp5r8cV7nly2iCDIPCpxXEGiAnbGyDNVJWYXNL RMg518rtrznN7mMvIeUUzIe5idpgA+MBVpUIdVIus51s9SKphoWirN/FpK/90CjRBu8d Eid9nry2JBLPMdJTw0p3bg25iO8LAp7gTQ7vCiPzS1FDYrjz+kG+EC4Zi2tcUJmXTcQH 9IDw== X-Gm-Message-State: AFqh2kodWSwKykKx8VvIQ8MXO497Npe1OObh6vutpyEtJ2DB4/eEPxE8 6jp64n8HjyuVFq/vx2t5XBHRtWwI1cNY5YkS9jjt2zRYCqOTahFDwzgGoeaxx95G/BijSRrwhQ6 eQTsvc9FTvmk/9nfOC4G2+XmEGeiDK6yhHbwAR9Z5bMACilZXR9DR4S3h+hB9dVgbSNasaUVG3A == X-Google-Smtp-Source: AMrXdXsSixWTfuKTghkEsCcpeXl31zB/hnFqKi9T6ZypfAlbhaGEub4x2DUOA6TMnrbTgpXhGHmwsw== X-Received: by 2002:a5e:9409:0:b0:6e2:c5e0:4c68 with SMTP id q9-20020a5e9409000000b006e2c5e04c68mr23140478ioj.13.1674696552772; Wed, 25 Jan 2023 17:29:12 -0800 (PST) Received: from mail-il1-f173.google.com (mail-il1-f173.google.com. [209.85.166.173]) by smtp.gmail.com with ESMTPSA id c8-20020a6bfd08000000b006bbfb3856d6sm1911235ioi.5.2023.01.25.17.29.11 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 25 Jan 2023 17:29:11 -0800 (PST) Received: by mail-il1-f173.google.com with SMTP id g15so278245ild.3 for ; Wed, 25 Jan 2023 17:29:11 -0800 (PST) X-Received: by 2002:a05:6e02:102a:b0:30f:641b:d141 with SMTP id o10-20020a056e02102a00b0030f641bd141mr2031486ilj.16.1674696551506; Wed, 25 Jan 2023 17:29:11 -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> In-Reply-To: From: Andrew Waterman Date: Wed, 25 Jan 2023 17:29:00 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 1/3] RISC-V: prefer SLT{,U} aliases for SLTI{,U} To: "Maciej W. Rozycki" Cc: Jan Beulich , Binutils , Palmer Dabbelt , Jim Wilson , Nelson Chu 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 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). 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). > > Maciej