From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0:4864:20::236]) by sourceware.org (Postfix) with ESMTPS id 20BF8385840A for ; Mon, 14 Feb 2022 10:35:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 20BF8385840A 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-oi1-x236.google.com with SMTP id m10so16896129oie.2 for ; Mon, 14 Feb 2022 02:35:31 -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=tu7+kZ0qBKksBrdYcnWzjUyD4vk/aPWc6UnT/5AzM2Q=; b=LJwCOKOszsB5K3Je7ddbn3ZcdD3UHg38Hu18Jbf98XRbNaUcdeDKBkKf3He2rL80R2 rgS9CH0oRQk9mbGpyrli3gp7X5Wlf4GEaf9gd+FTB8yHUN0EzsR0WuotyYvQBE1asGJE kIgUInkcERI8UE3TxTNddZPczq77jlaA/CvR+C9prrVZLZTPXrgSz9pe6AdclrGaepJz eZJiUEFfrvbS03l8eMCawZ8YdsN1QwqlpoQPsBFOIL38JhBiYtNocCBbrxwyKRC1282H XUhbKfKyqBd4mq4e7Goqn9ao0r28oGgKLQX1mTKEZHsFk5fKvV2BU/IFSKKabgRL3dvQ ZH9w== 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=tu7+kZ0qBKksBrdYcnWzjUyD4vk/aPWc6UnT/5AzM2Q=; b=QiY2ge1p8JNlt909heycW23XfY2CnuJQ0jsQ7hlwEIqeT8YhghFRDIHFTf9Q87TH9A qYu+rCNcbbFhJfwas61x/QUXhLOcaDPAk+Hsxcy9X2UkdVD3pYRmvzFF41Xay7hJ+U5N RgB9C3/utJQTQ+yP7JoepKRI/J9wdBl+UZvedEQ6iHmWfj7f+zesRQrq3vYzyp/alXZq Y6Gf4e9ncB1P3mv3h5qBcCmeyslfoceS6WN1jo/i0IAAmqskT0QWNI3t2KfXYEV2/IvY EOH0RKyu9TBKE+/u0y0oRluqJf4IS9w1N7nGbK3mVUZX1wzmHiNJ/wMsLi7grKQLKBb+ gFlA== X-Gm-Message-State: AOAM533m2+KOZWJvdr13uMDZfDZAL9mk70GkM6dz715EzwnP7P0hhTgL bEkD4gpZbs7EGc1fM9G6U/j7puTEFelnjg== X-Google-Smtp-Source: ABdhPJwYlVWCpGssVuI2QeBCNZQS09ttGDDXSuJ844/sEsAzoBR/j9M2cAhPngSsB+xYmqiqG208MA== X-Received: by 2002:a05:6808:150d:: with SMTP id u13mr5026915oiw.77.1644834930214; Mon, 14 Feb 2022 02:35:30 -0800 (PST) Received: from mail-oo1-f44.google.com (mail-oo1-f44.google.com. [209.85.161.44]) by smtp.gmail.com with ESMTPSA id x1sm12363383oto.38.2022.02.14.02.35.29 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Feb 2022 02:35:29 -0800 (PST) Received: by mail-oo1-f44.google.com with SMTP id t75-20020a4a3e4e000000b002e9c0821d78so18851972oot.4 for ; Mon, 14 Feb 2022 02:35:29 -0800 (PST) X-Received: by 2002:a05:6870:6187:: with SMTP id a7mr3667519oah.301.1644834929450; Mon, 14 Feb 2022 02:35:29 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Andrew Waterman Date: Mon, 14 Feb 2022 02:35:18 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: RISC-V: mapping symbols vs "unimpl" To: Jan Beulich Cc: Nelson Chu , Binutils Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-4.6 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, 14 Feb 2022 10:35:32 -0000 On Mon, Feb 14, 2022 at 12:27 AM Jan Beulich via Binutils wrote: > > Nelson, > > with your introduction of mapping symbols I have trouble expressing > certain spec-conforming deliberately illegal 32-bit instructions (low > 16 bits all zero). I can't use "unimpl" itself, as that for whichever > reason resolves to "csrrw x0, cycle, x0" I just wanted to remark on this seemingly arbitrary choice: we chose it because it's both architecturally guaranteed to be 32 bits wide and architecturally guaranteed to trap. (The CSR in question is definitionally read-only, and writing a read-only CSR must trap.) I realize it's of no help to your query, but I figured it was best not to leave this point dangling. > (and oddly enough using that > form as input goes through without even a warning, but that's just a > side note). I also can't use .insn, as that places requirements on > the low two bits of the main opcode. And now I also can't use .word > anymore, as that will cause mapping symbols to be inserted, which > therefore - by a disassembler honoring the mapping symbols - won't > disassemble as an instruction anymore. > > Do you have any suggestion how to encode a spec-conforming "unimpl", > which I want to be part of my own disassembler's test cases (in > particular the 0xffff0000 form)? Since the commit introducing the > mapping symbols refers to Arm, I'd like to point out that their .insn > equivalents allow to encode entirely arbitrary instruction forms. But > of course I understand that RISC-V's insn length encoding scheme is > somewhat in conflict with this. > > Two further remarks: Even ".insn ci ..." cannot be used, not even for > forms with the high 16 bits not all set (which again the main opcode > restriction would get in the way of): Already just temporarily > enabling RVC causes the RVC bit to be set in the ELF header flags. > Yet with that bit set 0xffff0000 is actually a 16-bit insn 0x0000 > followed by a wider insn with the low 16 bits all set. IOW this > conflicts with the spec's wording of "minimal length insn with the > low 16 bits all zero". > > And then I'm puzzled by the main opcode restriction related error > being raised a whopping 6 times for ".insn i 0, 0, x0, x30, ~0", > and still twice instead of just once for ".insn ci 3, 7, x31, ~0". > > Jan >