From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) by sourceware.org (Postfix) with ESMTPS id CDC3E3973047 for ; Thu, 23 Apr 2020 20:59:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org CDC3E3973047 Received: by mail-pf1-x436.google.com with SMTP id p25so3580119pfn.11 for ; Thu, 23 Apr 2020 13:59:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:subject:in-reply-to:cc:from:to:message-id :mime-version:content-transfer-encoding; bh=/MFzvuWAmRCWOxxkVkzO8C/dX2MsQQSvD2y9uKCsEhg=; b=py/S1POfD+iDnjvo+zbtOeGPqZrPOGLcef/xgKFe/SD0yOgpjsrKGQvdYhNNOjdis1 xECe72UBHCFcB7x5avWnB2pBjaCm+myG+BNo8+vhgUItamBEgoJ4VZTrTIt1DTUpt0Yk v5K8mOzUrNuDhhkUcS63UUSYagPjXDkJoenT8PAWuWXZjLxYLqgqpWcDgLVw1/iAp6y+ BsLEuhhZPz7yjE1goCLuYZjSsPtJ2bEs8hsghSEWmSolXvzHmzL8z8CalZQEWAuKrK6h JNzlfeo4k56kumR0oMAdN7y7lBeUQVfs1IE+e+/kldWR9iT2Wz0lgnWAd0xRo6D792kF 7IIQ== X-Gm-Message-State: AGi0PuYthLV+Nkws3KUJAl5gqq/Arary22ND1CrNjPs0bLyyleumfPmq tz1Zc+Cad4yqKXZLqZ5dvQBqRw== X-Google-Smtp-Source: APiQypInIBx5SrOmfbvkhhxr4s3QIJiII9WCLuEvgpXtGjKSHb3v16UJo+8E+z2J3DMuDHa5Je4ksQ== X-Received: by 2002:a63:9d8c:: with SMTP id i134mr5557965pgd.152.1587675581517; Thu, 23 Apr 2020 13:59:41 -0700 (PDT) Received: from localhost (76-210-143-223.lightspeed.sntcca.sbcglobal.net. [76.210.143.223]) by smtp.gmail.com with ESMTPSA id v1sm3422390pfn.212.2020.04.23.13.59.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Apr 2020 13:59:41 -0700 (PDT) Date: Thu, 23 Apr 2020 13:59:41 -0700 (PDT) X-Google-Original-Date: Thu, 23 Apr 2020 13:59:25 PDT (-0700) Subject: Re: [PATCH 0/7] RISC-V: Support version controling for ISA standard extensions and CSR In-Reply-To: CC: binutils@sourceware.org, gdb-patches@sourceware.org, Andrew Waterman , asb@lowrisc.org, maxim.blinov@embecosm.com, kito.cheng@sifive.com From: Palmer Dabbelt To: nelson.chu@sifive.com Message-ID: Mime-Version: 1.0 (MHng) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-18.8 required=5.0 tests=BAYES_00, DKIMWL_WL_MED, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, USER_IN_DEF_DKIM_WL, USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2020 20:59:45 -0000 On Sat, 18 Apr 2020 04:17:15 PDT (-0700), nelson.chu@sifive.com wrote: > Sorry for not sending these patches to Palmer :) > CC Palmer. That's fine, I subscribe to the lists :) > > Thanks > Nelson > > On Sat, Apr 18, 2020 at 7:08 PM Nelson Chu wrote: >> >> Hi binutils and gdb, >> >> I know every RISCV contirbutors all do the best to maintain the compatibility >> between different spec versions. But the specs are changed frequently, and >> sometimes it is very hard to keep the compatibility if we don't have a good >> way to deal with versioning problems. Since different ISA specs define >> different instructions, and different privilege specs define different CSR, >> both of them need the version checking and controling mechanism. >> >> For the ISA versions, you can set them by the RISCV ELF architecture attribute >> and assembler option -march, but you have to set them one by one for each >> extension. It seems not so friendly for user, so Kito Cheng proposed a good >> solution to resolve the problem. That is, support the new assembler options and >> default configure options to reduce the burdens when setting ISA versions. >> The original idea and discussion are come from the following link, >> >> https://groups.google.com/a/groups.riscv.org/forum/#!msg/sw-dev/aZhMG7NIVTk/PTZEaTWiAwAJ) >> >> === New Assembler Options === >> >> * -misa-spec = [2p0|2p1|2p2|20190608|20191213] >> You can simply choose the ISA spec by this option, and then assembler will set >> the version for the standard extensions if you don’t set in the ELF arch >> attributes or -march option. >> >> * -mriscv-isa-version = >> The syntax of is same as -march option, but without rv32 or rv64 >> prefix. There are two reasons that you may need this option, >> >> 1. Some versions of extensions defined in the ISA spec are not matched to the >> toolchain’s implementation. For example, V-ext is defined to version 0.7 in >> ISA spec, but we only have implementations for 0.8 and 0.9. Therefore, you >> have to use this option to choose the correct version for V-ext. >> >> 2. You want to update the version for the specific standard extensions if the >> version are not set in the ELF arch attributes and -march option. >> >> === New Default Configure Options === >> >> * --with-arch = >> The syntax of is same as -march option. Assembler will check this >> if -march option and ELF arch attributes aren’t set. >> >> * --with-isa-spec = [2p0|2p1|2p2|20190608|20191213] >> The syntax is same as -misa-spec option. Assembler will check this if >> -misa-spec option isn’t set. >> >> * --with-riscv-isa-version = >> The syntax of is same as -mriscv-isa-version option. Assembler >> will check this if -mriscv-isa-version option isn’t set. >> >> === The Priority of these options === >> >> * ELF arch attributes > Assembler options > Default configure options >> * For GAS options, -march > -mriscv-isa-version > -misa-spec >> * For configure options, --with-arch > --with-riscv-isa-version > --with-isa-spec >> >> === Example === >> >> $ cat test.s >> .attribute arch, "rv32i1p9fv_zicsr" >> >> $ riscv32-unknown-elf-as -march-attr -misa-spec=2p2 -mriscv-isa-version=i2p1a2p1v0p9 test.s -o test.o >> >> $ riscv32-unknown-elf-readelf -A test.o >> Attribute Section: riscv >> File Attributes >> Tag_RISCV_arch: "rv32i1p9_f2p0_v0p9_zicsr0p0" >> ... >> >> The above example covers most cases. >> >> * For i-ext, we already set the version 1p9 in elf attribute, so -misa-spec and >> -mriscv-isa-version don't update the version to 2p0 and 2p1. >> >> * For f-ext, we don't set the version to it, so use the default version 2p0 >> according to the ISA spec 2p2. >> >> * For v-ext, the default version is 0p7 according to ISA spec 2p2, but we use >> -mriscv-isa-version to update it to 0p9. >> >> * For a-ext, it isn't enabled by -march or elf attribute, so we don't update it's >> version even if -mriscv-isa-version is set. >> >> * As for the zicsr extension, it is defined in the lastest ISA spec rather than 2p2, >> so set it's version to 0p0. >> >> >> As for the privilege version, I get the related request in the following link, >> https://github.com/riscv/riscv-binutils-gdb/issues/202 >> >> We also support new assembler options to choose the spec you want, and then >> assembler will generate the correct CSR address according to the chosen spec. >> If the obselete CSR name is used, then report the warning message when the >> -mcsr-check is set, and use the latest defined address for the CSR. Of course, >> you can also choose the spec by setting the orginal RISCV ELF priv attributes. >> Beside, the disassembler can show the CSR according to the chosen privilege spec >> by the new disassmebler option. However, the CSR address is showed directly if >> it is invalid for the chosen spec. >> >> === New Assembler Option === >> >> * -mpriv-spec=[1p9|1p9p1|1p10|1p11] >> This is used to set the privileged spec’s version, and we can decide whether >> the CSR is valid or not. >> >> === New Default Configure Option === >> >> * --with-priv-spec = [1p9|1p9p1|1p10|1p11] >> The syntax is same as -mpriv-spec option. Assembler will check this setting >> if -mpriv-spec option isn’t set. >> >> === New Disassmebler Option === >> >> * -Mpriv-spec=[1p9|1p9p1|1p10|1p11] >> The syntax is same as -mpriv-spec option. The disassembler can show the CSR >> correctly according to the chosen privilege spec. >> >> >> Notes, >> >> 1. I'm not sure if GDB needs the above version checking, but I think the current >> modifications won't change the behavior of GDB. We still use the DECLARE_CSR >> to generate the gdb/features/riscv/[32|64]bit-csr.xml, that means we only generate >> the CSR which are valid in the latest privilege spec. Also, the objdump shows >> the CSR according to the latest privilege spec by default. >> >> 2. The default ISA spec is set to 2p2 rather than the lastest version. The reason >> is that compiler generates the ISA string with fixed 2p0 verisons only for the >> RISCV ELF architecture attributes, but not for the -march option. Therefore, we >> should update the compiler or linker to resolve this problem in the futrue patches. >> >> 3. How to extend the default versions and new ISA spec? >> You only need to update the riscv_ext_version_table which is defined in the >> opcodes/riscv-opc.c. >> >> const struct riscv_ext_version riscv_ext_version_table[] = >> { >> /* name, spec name, major, minor. */ >> {"e", "20191213", 1, 9}, >> {"e", "20190608", 1, 9}, >> {"e", "2p2", 1, 9}, >> >> {"i", "20191213", 2, 1}, >> {"i", "20190608", 2, 1}, >> {"i", "2p2", 2, 0}, >> ... >> }; >> >> 4. How to extend new privilege spec and new CSR? >> >> * include/opcode/riscv.h >> enum riscv_csr_vclass >> { >> CSR_CLASS_VNONE, /* Default value */ >> >> CSR_CLASS_V1P9, /* v1.9 */ >> CSR_CLASS_V1P9P1, /* v1.9.1 */ >> CSR_CLASS_V1P10, /* v1.10 */ >> CSR_CLASS_V1P11, /* v1.11 */ >> CSR_CLASS_VDRAFT >> }; >> >> * opcodes/riscv-opc.c >> >> static const struct priv_version_t priv_versions[] = >> { >> {"1p9", CSR_CLASS_V1P9}, >> {"1p9p1", CSR_CLASS_V1P9P1}, >> {"1p10", CSR_CLASS_V1P10}, >> {"1p11", CSR_CLASS_V1P11}, >> >> /* Terminate the list. */ >> {NULL, 0} >> }; >> >> * include/opcode/riscv-opc.h >> >> Format, DECLARE_CSR (NAME, VALUE, CLASS, DEFINE_VER, ABORT_VER) >> DECLARE_CSR_ALIAS(NAME, VALUE, CLASS, DEFINE_VER, ABORT_VER) >> >> NAME: CSR name. >> VALUE: CSR address >> CLASS: ISA dependency >> DEFINE_VER: First defined in which privilege spec. >> ABORT_VER: Aborted in which privilege spec. If the CSR is still valid in >> the lastest version, then it should be CSR_CLASS_VDRAFT. >> >> If the CSR is aborted in the latest spec, or has not only one information, then >> use DECLARE_CSR_ALIAS. Otherwise, use DECLARE_CSR. >> >> For example, >> DECLARE_CSR(ustatus, CSR_USTATUS, CSR_CLASS_I, CSR_CLASS_V1P9, CSR_CLASS_VDRAFT) >> DECLARE_CSR_ALIAS(ubadaddr, CSR_UTVAL, CSR_CLASS_I, CSR_CLASS_V1P9, CSR_CLASS_V1P10) >> >> >> Thanks >> Nelson >>