From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oo1-xc2e.google.com (mail-oo1-xc2e.google.com [IPv6:2607:f8b0:4864:20::c2e]) by sourceware.org (Postfix) with ESMTPS id EECE13858C83 for ; Mon, 28 Feb 2022 03:21:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org EECE13858C83 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-oo1-xc2e.google.com with SMTP id x6-20020a4a4106000000b003193022319cso16950559ooa.4 for ; Sun, 27 Feb 2022 19:21:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9px2dkrWc9xPKLDsHpAnc2fxj1ca8p8q5fuiWD7csLc=; b=fiBWLb1ij47uat7fzQstWDHPy8vLAd8husWyephl9K4dJ/QlzajrMsND00ygbTW4yn mkXqsTezbTC8aAjlOU3khIr4O6czrOM1Eo+nSarHvCorlX/zkOA0o34UJ2egBHKqN5pR 4jpI+kWF1TAEsU4Jt5btkOi6lsteztX79kCVa1ErnfUjJiCVnUYw1eFf4dyozHpEZt1h NENWrOQi7WevALZ6DPmdpFeeznCQ2LZgZoY5BzTFeMLSJqhX8uWG5y/KdjQDRFLgCXOr QnGvbFVK58SatP/IXeTQZ+VJLGU8Ag/POsndyrjo1tM28vbOxRrNkcUmcEQJvoQ6zZz0 pGcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9px2dkrWc9xPKLDsHpAnc2fxj1ca8p8q5fuiWD7csLc=; b=2JO6MfU5L2hzhH05OvULOCLAanFWeaZXiGCxHNppcfzK1dycwnV2l3vzqK/95UI4zc XkiUZlcmp+QSgpbiFgnICCBg2JODCd+nO9hEMFuVX+lxjr8sSrLCc/vhe6u+uzPZbxFf QcZ8WkvnGg1dJzt70FeD97FV29g18xRbsHSc3UTvYFNQ1ZXkA+rP76hASpX/6/Hf+zEN aAZovt1VXO/EGfMT7MYD9ktVJJoEeaguLX4gxmNLF2XPABw1gz2H7YOWo/CmHt89Ap9j fJVXvIriJOt3NArpCV8GD1b6Qy5Ukz/Y+g14utT00FZXfkHL1nva2dy4uyriR50ICfhx 5q0Q== X-Gm-Message-State: AOAM530XjxCzrzX8yAXk++h8HQzERsx0uljt47Os4yUcRUaQGqZd8P/W m3vNmdAQkL741ihEydFqU5o6j+Fj18r4oA== X-Google-Smtp-Source: ABdhPJwq9+ECk0fBW15/IH+ZG53BI8ZhXcHI06+3vOBXXKNjfrq1rLQfjsI6ncEj3wcEJbrwix15mg== X-Received: by 2002:a05:6870:1210:b0:d6:ea77:997e with SMTP id 16-20020a056870121000b000d6ea77997emr6360357oan.278.1646018460142; Sun, 27 Feb 2022 19:21:00 -0800 (PST) Received: from mail-ot1-f41.google.com (mail-ot1-f41.google.com. [209.85.210.41]) by smtp.gmail.com with ESMTPSA id bx11-20020a0568081b0b00b002d721fa20f2sm5487945oib.17.2022.02.27.19.20.59 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 27 Feb 2022 19:20:59 -0800 (PST) Received: by mail-ot1-f41.google.com with SMTP id a7-20020a9d5c87000000b005ad1467cb59so8483781oti.5 for ; Sun, 27 Feb 2022 19:20:59 -0800 (PST) X-Received: by 2002:a9d:2257:0:b0:5af:7092:2688 with SMTP id o81-20020a9d2257000000b005af70922688mr8153455ota.105.1646018459275; Sun, 27 Feb 2022 19:20:59 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Andrew Waterman Date: Sun, 27 Feb 2022 19:20:48 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: RISC-V: observations / questions To: Jan Beulich Cc: Palmer Dabbelt , Jim Wilson , Nelson Chu , Binutils Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-4.4 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, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2022 03:21:02 -0000 On Fri, Feb 25, 2022 at 6:59 AM Jan Beulich wrote: > > Hello, > > besides the two relatively simple patches that I have sent earlier > today, I do have a few more questions: > > 1) Many insn encodings using x0 as the destination are marked as hint > encodings. Wouldn't things like "add x0, x1, x2" therefore better be > at least warned about? Encodings like that should not issue warnings, for a few reasons: - It's always functionally correct to include stray HINTs in programs, since by definition they don't affect architectural state. - This style provides a clean way to encode hints before they've been added to binutils. - This style facilitates writing test programs. > > 2) Insns like "beq x0, x0, ." (perhaps not very useful outside of > assembler / disassembler test suites) result in odd ".L0 " labels in > the object's symbol table. My best guess so far was that this may be > a result of "#define tc_fix_adjustable(fixp) 0". As these labels are > somewhat confusing - would there be a way to suppress their emission? > > 3) When the assembler can determine a branch's destination, e.g. in > "beq x0, x0, .+1", wouldn't it be useful to warn about the non-even > destination address? And with the C extension disabled even about > any one not evenly divisible by 4? (Only in response to the second question:) It's legal to include branches to addresses that aren't divisible by 4 (but are divisible by 2) when C is disabled; the trap only occurs if the branch is taken. Prohibiting these branches' inclusion would make it harder to write test programs. > > 4) A number of CSRs are valid in RV32 mode only. Shouldn't their use > be diagnosed when assembling 64-bit code? (I thought I had seen a > patch to this effect, but not overly old gas still happily accepts > them.) > > 5) While possibly not too interesting for RV32, in RV64 auipc and > lui have immediate operands which are sign-extended. Yet gas chokes > on any of > > auipc x31, -0x100 > lui x31, -0x100 > c.lui x31, -0x20 > > Shouldn't signed operands be permitted (if not required) there, and > then ideally permitted (but not required) also on RV32? IMO, changing the set of immediates that these instructions can accept risks causing more confusion than it resolves. Part of the reason is they already accept large unsigned immediates (e.g., lui t0, 0xfffff), which is an odd holdover from the MIPS assembler, but one we can't change for backwards-compatibility reasons. IMO, it seems a bit funky to accept both [-0x80000, -1] and [0x80000, 0xfffff] to refer to the same set of numbers. > > Thanks for any helpful insight, > Jan >