From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) by sourceware.org (Postfix) with ESMTPS id 36E113858D39 for ; Sun, 26 Mar 2023 15:43:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 36E113858D39 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pl1-x634.google.com with SMTP id o11so6213485ple.1 for ; Sun, 26 Mar 2023 08:43:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679845409; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=va1Sk7FmyAAw+Wid4oPL7776NymXruRNq5majAd+2KQ=; b=N/7jYdmYJWcp1vs/ZxAJIJZ8F1kX8DLkaR/VDgtiyNsYvWsoQ5PPh1eKBC1Rbdfk9L GLy7wTTMNboDCLBH1NIqMbB8mmL1rOtgHhSfNz9VesoJpfY/WDl1HeU1Yiv+crWfgdjj klnlje664knt3Kvu/Djt6pqremaKkzF5dgqwKmuTjSdpj5bxamPACVof0LuJx2KUezRW qghHWabm6DxAJs3h1Hz/EumVysxFdLWpWLDLQB1xwvix1wvGDhGDnRIC/E0M5EkR8/tw ypB9m7sZbz8p9/0mjq5kq5Kmi54iaeeZL86e9a5mcHb2ZDGRC/SoDSRIr3MIyjIRLNwm Dg6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679845409; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=va1Sk7FmyAAw+Wid4oPL7776NymXruRNq5majAd+2KQ=; b=hfRu1RDbV5/j0HAlbeeK9Js0CvV8K2pM8xCqJUJroWcr/la/gA2GNJf2aFH+o7pi35 ub43L67C7Svbdd5KzKHsFbEq77+EnTV3fBI39njiBzi+viCIsbjyd3GhvTH9veFLGSAk bMPSrTurzVCHxzS89jioy4HFWYk1dvg51bQjxtyaYYGjzwxzzBkNeyzXXr38BcAlFLTk MvKfkQyH+RW0vHc5IAqkOI7pVT6E/aT+UipYsbRZGdffiRBRQZ4SeqBV9U40Ct8icrOt 7IlrEd1xIg/s6tiRCzlJgE6UyOGHoFghyc9H5I3qBzYI+4lRe2XIePJcN9R0FD7BQx3l JNZw== X-Gm-Message-State: AO0yUKUOl2Ve3f2zWgkxq0xEQBj8xZTV/TC/Kx5zO/Cztxb+3z0Z28We z+NmQO4GNojy73yF9maTLZ0= X-Google-Smtp-Source: AK7set8oTueRVUtaf8E1kyNIaYZCfEqOuYq1Z48g+MRok3rPMLyptFG3lxPZehGABhhZiY41yxOx/A== X-Received: by 2002:a05:6a20:2da6:b0:d8:decb:3419 with SMTP id bf38-20020a056a202da600b000d8decb3419mr9501295pzb.40.1679845409093; Sun, 26 Mar 2023 08:43:29 -0700 (PDT) Received: from ?IPV6:2601:681:8600:13d0::f0a? ([2601:681:8600:13d0::f0a]) by smtp.gmail.com with ESMTPSA id g13-20020a62e30d000000b0062a51587499sm6448691pfh.109.2023.03.26.08.43.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 26 Mar 2023 08:43:28 -0700 (PDT) Message-ID: <4e49a63b-4a0b-6e58-1c94-40d515244f9e@gmail.com> Date: Sun, 26 Mar 2023 09:43:27 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Subject: Re: [REVIEW ONLY 1/1] UNRATIFIED RISC-V: Add 'Zfa' extension Content-Language: en-US To: =?UTF-8?Q?Christoph_M=c3=bcllner?= , Tsukasa OI Cc: binutils@sourceware.org, Philipp Tomsich , Andrew Waterman References: From: Jeff Law In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 3/22/23 09:47, Christoph Müllner 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=0 > fli.h ft1, min # encoding rs1=1 > fli.h ft1, 0.0000152587890625 # encoding rs1=2 > ... > fli.h ft1, 16 # encoding rs1=25 > ... > fli.h ft1, nan # encoding rs1=31 > > 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. 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. 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