From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) by sourceware.org (Postfix) with ESMTPS id B623B3955417 for ; Wed, 24 Feb 2021 20:18:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org B623B3955417 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=sifive.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=jimw@sifive.com Received: by mail-ed1-x52d.google.com with SMTP id p2so4124019edm.12 for ; Wed, 24 Feb 2021 12:18:44 -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=SAL5poAc9ibTeJcpUW2wyD0qFLAmPLOmsb7CjHxnzaY=; b=mvR9fCAnJZ7wqK20toV4PaSraL2BWm8F2oALdhJIH+Z67XOPBSuzR6PozsqyeM1Tgg DWUR72RWyDOlhu0TgreKxC/N3XDlo9BcZ6e0N45faudOMvkWyQHSmWxsBwlewz6RCcjo 2gfS2fC1dAEeeRB5fANb0nKHRKYVaZGkO17OQ3jEGm19SMyUK9m/sSGNQ0fEzT167z77 IBnwesHOkiTpEH0PwDx6yi9RCO98KMioSMopF5267YkFXJbxxu2QkvAn0EEk1mDMF6UK Tj1JzDetgP1Dl8wIOEcwKqQycNDn6EZm+Yh/yXLN6Sl+ByhpuRRgAYOYkxghvpq6Ua0C POnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SAL5poAc9ibTeJcpUW2wyD0qFLAmPLOmsb7CjHxnzaY=; b=jHPK6qkjeEiszD5mvfjRMkiMjxJbVGhNlscmqZkrcgeENu73qwuaEVl4N6MxSZ/TSw hZC46RwphKDJ24hgMycsnnXDLY6qfHzD34/4rZGOyXDUbzCRbQsrBhfov05grWxnjNY/ JtIYi9GHlcyNXzmvWEbL3m9lVIEkj3b2ZsUGlZTBpo9W/ta0a8/T4FIBsGoBOD4idReC V/qep2MHjnQSijT+Tew2VvHcA3hyE+3apsKkNAjLa8rXRwSP17wwQLogxfz/tYAO4PdJ jrwPmCpzwnhd7aoRKQR8OMQ5Z9dz5ctJib6het60f8RGwl4WY8ioaOha5WgpkzGHERdj HTnQ== X-Gm-Message-State: AOAM533fTKWOBYqlGMsJE9gIKnSOkLXou7Eb7hx4h9mW6V02fNTsdomR qOmLWRmj6BKMQAtInbZO0OJnklOaRFwlfReeiUd8+A== X-Google-Smtp-Source: ABdhPJwV9ke6RFQ3Z3/FkvgzRAvCzIVDJIi3/tt758voWXEVsdVXZbiZC4p3T7azIgSo0R/Eoynz8J9Nw3dK/GL/uJM= X-Received: by 2002:a05:6402:95b:: with SMTP id h27mr21085306edz.77.1614197923436; Wed, 24 Feb 2021 12:18:43 -0800 (PST) MIME-Version: 1.0 References: <28104a54-9f49-fd00-9aa0-29b6aa864205@suse.com> In-Reply-To: <28104a54-9f49-fd00-9aa0-29b6aa864205@suse.com> From: Jim Wilson Date: Wed, 24 Feb 2021 12:18:32 -0800 Message-ID: Subject: Re: [PATCH] RISC-V : Support bitmanip-0.93 ZBA/ZBB/ZBC instructions To: Jan Beulich Cc: Kuan-Lin Chen , "binutils@sourceware.org Development" , Palmer Dabbelt , Nelson Chu X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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: Wed, 24 Feb 2021 20:18:46 -0000 On Wed, Feb 24, 2021 at 1:19 AM Jan Beulich wrote: > I notice the xor vs xnor testsuite aspect pointed out in my > post from Jan 18th was addressed, but the other questions > remain: > We had to rewrite the patch from scratch due to a copyright assignment problem. So there could be no progress until we had the new patch. The new patch doesn't repeat the xor mistake in the original patch. > > For consistency with other insns taking immediate operands, > shouldn't slli.uw one have a sll.uw alias? > Yes, that makes sense. We can add that in a follow on patch. > > Also two perhaps more spec related questions: Why does slli.uw > allow for 7-bit wide shamt? Any shift count 32 and up is not > in need of this new insn, as slli will yield the same result. > (I could see the need in RV128, where counts up to 95 would be > needed, but right now talk is - I take it - mainly of RV32 and > RV64.) > RV128 needs 7 bits for shift counts. So we have to reserve 7 bits in the encoding for future expansion. slli.uw only uses 5 bits of that field. slli.uw uses the same instruction format as other instructions that can use the entire 7 bits of the shift count, which is why the field needs to be 7 bits. This is done to reduce the number of instruction formats that need to be decoded. But a slli.uw with either of the upper 2 bits set should probably be a reserved encoding. Or maybe use a different encoding. This should be raised with the bitmanip committee. > > The current draft also doesn't say anything about hints; one > could assume destination being x0 may get treated the same as > in the base spec, but in the absence of this being said > explicitly one could as well imply these are all simply > sort-of-nop-s, or even illegal. > They are all nops. And all hints use nop encodings. A hint is supposed to be executed as a nop, except when it is a hint. This makes it safe to use a hint anywhere. Since it will be executed as a nop if the hardware doesn't support the hint. But this is another issue for the bitmanip committee, whether the new nop encodings should be allowed to be used for hints. Jim