From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) by sourceware.org (Postfix) with ESMTPS id 6195D3857006 for ; Mon, 17 Jul 2023 07:20:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6195D3857006 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=vrull.eu Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=vrull.eu Received: by mail-wr1-x42c.google.com with SMTP id ffacd0b85a97d-3142970df44so3986145f8f.3 for ; Mon, 17 Jul 2023 00:20:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vrull.eu; s=google; t=1689578439; x=1692170439; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=fXbi9dVuSt68Av/lhjumL7lXfAtGV84f4rvM9/56/M0=; b=SIXn2Bx/6exfRBRKBZSZSvLKSWVZjtKh+hwBqSBZpIIFgVdrD4ECFk7vuV65rerqo4 IOE8faXw3I6bqKe404onMx1DyRxcUVAI6n7IDC9dW267mWAacsKswo8kUieTRiwbyU8Z TUUN+j1BuBUkPvcaABVdDub2fvEKPoZwAmHXgiHNF6r5gwodmUODdJLFWi7U6lo0Oklb 6LYvQl+wGDIi5pWQly65nASa9WCcqZVJNWgsUXfNzbFCH6EpzUZha8Aa3P2/1ZtzAWZL /iJSM+jDNoWeTA0J7vkTg5aYaWIH8qT5uehV5Ys0NVvN7hzdMgxkYafXJOHxARJq2Y5O z86A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689578439; x=1692170439; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=fXbi9dVuSt68Av/lhjumL7lXfAtGV84f4rvM9/56/M0=; b=dF+xD1n519zWPJqCHpGMq5ZRcnys11wP5CSLoRw/JjXBE7g7z78EfeuX6f+hVNNaYk YoQUVZ6DRNxkdVJtY3HQ2O7D1n2H2H9Y+NpNIFcUx9PLoUbqOZC3kVj4L712mUuXlNVT FQgBwrTdkN4q+elybZ2ajZXxXJYTjudTugTMEyQoSF8UBJyx6anEVK0O8BONVbC1hXCG wpnpB0+rpH6XRgSwdKQoyQWgpL/fqYUBpRYOhAssaiFO6oRgouCLJpWH6XJvClBvG2vU UlKLMzE9QB8Ne1BvfhhcYDs7NHHHfPKImt0DgPhNC2EU6d2rLLF5k4VYSVKR88AaiH+w dIrQ== X-Gm-Message-State: ABy/qLZomBsZWQTYdOcaCloAb9MBDnsvRGm1uDPjOF8bHbIefHeZO+1D 0JrS/JM2qTYv+1oI1OliTupLt4S//6ph16arfx3UIf9VQrVrfx9YV6A= X-Google-Smtp-Source: APBJJlFqGhzu2zX2g21getNxAliyklBOwu0FW/e/8vRzsSx0jSjEr1f2e3PQ8bum6yVUmN8wNMgv/mPQ5omxJUAWSLQ= X-Received: by 2002:adf:d0d1:0:b0:314:824:3777 with SMTP id z17-20020adfd0d1000000b0031408243777mr8422778wrh.48.1689578439195; Mon, 17 Jul 2023 00:20:39 -0700 (PDT) MIME-Version: 1.0 References: <20230701052104.4018352-1-christoph.muellner@vrull.eu> <20230701052104.4018352-3-christoph.muellner@vrull.eu> <355e3b07-3111-34dc-7b0f-8be828012ae4@suse.com> In-Reply-To: <355e3b07-3111-34dc-7b0f-8be828012ae4@suse.com> From: =?UTF-8?Q?Christoph_M=C3=BCllner?= Date: Mon, 17 Jul 2023 09:20:26 +0200 Message-ID: Subject: Re: [PATCH v6 02/15] RISC-V: Add support for the Zvbc extension To: Ken Dockser , Nicolas Brunie Cc: binutils@sourceware.org, Nathan Huckleberry , nhuck@pmull.org, Jeff Law , Nelson Chu , Andrew Waterman , Palmer Dabbelt , Jim Wilson , Philipp Tomsich , Jan Beulich Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,JMQ_SPF_NEUTRAL,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: +Ken Dockser +Nicolas Brunie I've added Ken and Nicolas (spec authors) to give an authoritative answer, = and because this looks like a valid public-review comment for the specification= . The spec indeed mentions "the 64-bit value from integer register rs1 (vector-scalar)", which is unclear for RV32. BR Christoph On Mon, Jul 17, 2023 at 9:02=E2=80=AFAM Jan Beulich wro= te: > > On 01.07.2023 07:20, Christoph Muellner wrote: > > --- a/opcodes/riscv-opc.c > > +++ b/opcodes/riscv-opc.c > > @@ -1902,6 +1902,12 @@ const struct riscv_opcode riscv_opcodes[] =3D > > {"vwsll.vx", 0, INSN_CLASS_ZVBB, "Vd,Vt,sVm", MATCH_VWSLL_VX, MASK_= VWSLL_VX, match_opcode, 0}, > > {"vwsll.vi", 0, INSN_CLASS_ZVBB, "Vd,Vt,VjVm", MATCH_VWSLL_VI, MASK= _VWSLL_VI, match_opcode, 0}, > > > > +/* Zvbc instructions. */ > > +{"vclmul.vv", 0, INSN_CLASS_ZVBC, "Vd,Vt,VsVm", MATCH_VCLMUL_VV, MAS= K_VCLMUL_VV, match_opcode, 0}, > > +{"vclmul.vx", 0, INSN_CLASS_ZVBC, "Vd,Vt,sVm", MATCH_VCLMUL_VX, MASK= _VCLMUL_VX, match_opcode, 0}, > > I realize this is more a spec question than an implementation one, but > implementation might be affected by the answer to the question: What > exactly are this and ... > > > +{"vclmulh.vv", 0, INSN_CLASS_ZVBC, "Vd,Vt,VsVm", MATCH_VCLMULH_VV, M= ASK_VCLMULH_VV, match_opcode, 0}, > > +{"vclmulh.vx", 0, INSN_CLASS_ZVBC, "Vd,Vt,sVm", MATCH_VCLMULH_VX, MA= SK_VCLMULH_VX, match_opcode, 0}, > > ... this insn doing in RV32 mode? There are no 64 bits to take from > the GPR, yet that's what the doc presently says. Is the value coming > from a pair of GPRs, or is it sign- or zero-extended? Or is this an > RV64-only insn? (Note how the doc explicitly describes the behavior > for vandn's scalar-source form; the only thing left to be implied > there is that truncation / sign-extension are to - I assume - element > size, but maybe that's said somewhere in more general terms.) > > As a nit: The two vclmulh lines have one too many blanks, resulting > in columns to not be aligned. > > Jan