From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-sender-0.a4lg.com (mail-sender.a4lg.com [153.120.152.154]) by sourceware.org (Postfix) with ESMTPS id 04BF2385842A for ; Sun, 6 Aug 2023 02:41:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 04BF2385842A Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=irq.a4lg.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=irq.a4lg.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail-sender-0.a4lg.com (Postfix) with ESMTPSA id 81699300089; Sun, 6 Aug 2023 02:41:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=irq.a4lg.com; s=2017s01; t=1691289706; bh=56a72uvJgYJ5g+WUj9pr9BGsEwTntzJo18GGXGS7XW0=; h=Message-ID:Date:Mime-Version:Subject:To:References:Cc:From: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=MhvHMbUEY45EG8lE3M6daITK8QDvuFPfj2QzsKqRqiILakWCZMJsQy5OqE0TqTVEd vuL9pJx9ARBpSLYjhMtpL9p0WB9xD0+8ufpFSoJ06oOeM9FYx+o/+04pgde88rbGtY P1QqfWEF6kc23JNT26Kwg34OQGGTztKtCQgAI6nc= Message-ID: <0e90327b-706b-4095-aa1c-4586790b7280@irq.a4lg.com> Date: Sun, 6 Aug 2023 11:41:46 +0900 Mime-Version: 1.0 Subject: Re: Instructions argument string Content-Language: en-US To: Jacob Navia References: <3BDEF2AE-C21C-4FA6-AAE0-F02813C954C7@gmail.com> Cc: binutils@sourceware.org From: Tsukasa OI In-Reply-To: <3BDEF2AE-C21C-4FA6-AAE0-F02813C954C7@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 2023/07/23 5:32, Jacob Navia via Binutils wrote: > Hi > > I am trying to document and decipher the « argument strings » that are stored as character strings in the risk_opcode opcode table. They are strings like "Ct,Cc,CK » or "Ct,Cc,CK ». They are interpreted in the function riscv_ip. Is there anywhere a documentation as to the workings of the interpreter, i.e. which do the letters actually mean? Unfortunately, none. Those operands are subject to change in any time and in fact, it changed. An example is "f" [fetch offset to the 'Zicbop' extension HINTs] to "Wif" (to vacate one-letter operand character space and prepare for other operands that would be too much for one-letter space such as "Wfv" [the 'Zfa' extension; floating point operand of FLI instructions]). I'm afraid to say, the source code is the best documentation. I once made a list (to prune unused operand strings; for the following patch set) but now the list is outdated and it doesn't have any documentation. At least I can provide an advise. When I forget some details about operand string, I mainly see three functions and I personally prefer print_insn_args (though I use other two functions when necessary). gas/config/tc-riscv.c: validate_riscv_insn It can be a quick reference to indicate which bits are used. gas/config/tc-riscv.c: riscv_ip It's the main parser. If you wonder any instruction operand formats, it's the best place to look at. But it's also the most complex function which uses operand string. So, if I forget something about operand string, it's the last function to see. opcodes/riscv-dis.c: print_insn_args It's the main printer for the disassembler (objdump and GDB). It's not self-explanatory as validate_riscv_insn but provides many information yet easier to read than riscv_ip. I understand that this is not a satisfactory answer for you but still the best I got now. Thanks, Tsukasa > > Of course it is not very difficult to follow the code, but it would be better if a table would exist somewhere that describes the workings in a higher level language, i.e. a human language like English. > > Thanks in advance for any information you have. > > Jacob > > P.S. Of course, the documentation I am writing will be open sourced with the same license as your documentation.