From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) by sourceware.org (Postfix) with ESMTPS id 3DD10385840D for ; Mon, 27 Mar 2023 00:14:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3DD10385840D 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-ed1-x535.google.com with SMTP id cn12so29186729edb.4 for ; Sun, 26 Mar 2023 17:14:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vrull.eu; s=google; t=1679876050; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=DGZWLPaVCDmZ7DkO7LH+uVCs7U+UlTtLTE//OrEdYys=; b=q1FXLvw3Z0LjSgabseI4nW8wVCDvRDOrIsBdpORZJY+cCaqkqGO/B0IbfZcWkqK67L ltiUGxDsLLsqQPvDXGau3YdY6bx0masPQi/9Wt04SMxjc8cvB8piQR053W7Qid1U8ASN 5xnKLYb0fV+T4FqJrXwEKXKS45MfuGd40Mkqe+DrYkNlW9ccdCevE2WerQ7H+fpkH6Ei HOmkT0ZX2bxkNpvEdkehDwSeE1DbtxQjxB5YFVKU+asB3I4e2cGif4+xfqkVokWK7JX3 +zOqMyZVzliNgBvC2ZcjCEjXLr9Yy1HVHrGCBPdKHA/tE4CkHsx250FlqCzWDRw/xCi8 ffQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679876050; h=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=DGZWLPaVCDmZ7DkO7LH+uVCs7U+UlTtLTE//OrEdYys=; b=wTU/+xCPUIEjfZjamntrRAOQTVRIcyMtXujrMncSiHOshG8hmU51/hig2LUeU0wBQW Ffn8We1jGeIqxTRL9PlHKLxh1QMbLvF0ewpGMS7I4KejV+xPw1MSId1v7RMfYa755XFZ ctpXiG94t4QHFPMOyAyFiBaoqHhkT4/YUSnhXiPcOk634HuXBSXMNKgtXApbtCsVEXTC 8/x9BH+iae9ZaFWF+8nE2yBEySK+zyrOa2/ycIAoFpBIT1Kf+ejkvMUyKhrY4mA2HBkb IMY1I1n/1RwKzLnRjTMfpqrXFeG4kYU6n7NgsNkJFixY1MYrb+EHFK7GGd5mAewwPSW6 0EEQ== X-Gm-Message-State: AAQBX9dQe1/r7wAQrrmE0ma58VmHKQzgll/skkAoUPhO0u0fgPf9Tq9S Jbi5PRz+Q60BOrHWsWF1uVqBdZVh98l13BqznnbaxVQLDcbhTlYDdp5XBA== X-Google-Smtp-Source: AKy350btnlntfpBkoMepi+0W9i3kU45lpe66wFTr8oKN6d8ipWIzWa6+ezsnW+Tt3ce/0jQhjiUJg8dW1QmGHTH47nI= X-Received: by 2002:a17:906:6a2a:b0:929:ac47:f0ad with SMTP id qw42-20020a1709066a2a00b00929ac47f0admr4378153ejc.1.1679876049760; Sun, 26 Mar 2023 17:14:09 -0700 (PDT) MIME-Version: 1.0 References: <4e49a63b-4a0b-6e58-1c94-40d515244f9e@gmail.com> In-Reply-To: <4e49a63b-4a0b-6e58-1c94-40d515244f9e@gmail.com> From: Philipp Tomsich Date: Mon, 27 Mar 2023 08:13:58 +0800 Message-ID: Subject: Re: [REVIEW ONLY 1/1] UNRATIFIED RISC-V: Add 'Zfa' extension To: Jeff Law Cc: Andrew Waterman , =?UTF-8?Q?Christoph_M=C3=BCllner?= , Tsukasa OI , binutils@sourceware.org Content-Type: multipart/alternative; boundary="00000000000036871005f7d69f08" X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,HTML_MESSAGE,JMQ_SPF_NEUTRAL,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP 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: --00000000000036871005f7d69f08 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun 26. Mar 2023 at 23:43, Jeff Law wrote: > > > On 3/22/23 09:47, Christoph M=C3=BCllner wrote: > > > > > Hi Tsukasa, > > > > There seems to be a misunderstanding of the spec. > > The second operand of the fli should be the constant itself ("Value" > > column of the specification) in C-like syntax. > > E.g.: > > fli.h ft1, -1.0 # encoding rs1=3D0 > > fli.h ft1, min # encoding rs1=3D1 > > fli.h ft1, 0.0000152587890625 # encoding rs1=3D2 > > ... > > fli.h ft1, 16 # encoding rs1=3D25 > > ... > > fli.h ft1, nan # encoding rs1=3D31 > > > > So we have 3 strings ("min", "inf", "nan") and 29 constants. > Ouch. So we've got to parse & match the actual constant. I worked on a > processor with similar capabilities, but we defined the assembly syntax > to use the table index for the constant rather than the constant itself. > I'd strongly suggest supporting the %a/%A hex notation for the > constants. It's unambiguous and less error prone. I think Kito made a > similar suggestion downthread. That had been my initial reaction as well, when discussing the expected assembly syntax with Andrew (the specification was not explicit enough to me, as the table index will also be a decimal constant). However, after giving it a little thought, matching the FP-constant dies offer its own set of advantages: (a) it makes it clear to assembly writers and (more importantly) readers what numeric value is intended; if we use the table index only, the typical use will have a comment with the value next to it (b) it is a clear improvement over today (where either the hex-representation will be in the constant pool or a load-imm sequence will be used). Accepting both notations (possibly prefixing the index with #) sounds reasonable. For disassembly, the fp-constant is preferable =E2=80=A6 sane f= or compiler output (unless we want to emit a comment for verbose-asm). The extra effort to handle the FP constants in the assembler certainly seems worth the improved readability of the assembly. When I read through the basics of Zfa I was a bit disappointed. 99% of > the time the fli is going to feed one or more FP arithmetic > instructions. As the ship for fp-immediates in fp-arith has sailed (at least in the 32 bit encoding space), this fli-construction will at least offer opportunities for fast result forwarding/bypass or for instruction fusion. It'd be more efficient to be able to access those FP > constants in the FP arithmetic instruction itself. I guess that ship > has sailed. > > Jeff > --00000000000036871005f7d69f08--