From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) by sourceware.org (Postfix) with ESMTPS id CD97D3858CDA for ; Thu, 30 Mar 2023 16:59:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CD97D3858CDA 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-x433.google.com with SMTP id e18so19788964wra.9 for ; Thu, 30 Mar 2023 09:59:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vrull.eu; s=google; t=1680195566; 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=q3Db68FKTl1xzxGqmcdObvg67qsPDOpji62Lx3fISMU=; b=pTuywwnQezkJBJGhEhRSm/n/lLL2zw9ZHw2+tumQHBGK8om8rY8OsSGV/eYV6dpiDV +sJsBwm/GLTdLq6mcbalmOy3SCUIkxqjbg7eGtMCX8MDzpliruclzwndq5538cRwG0nB Zz61l9R/bYbg3N5yjoZwOVfsJLYZDOE/+xxp3tcZXQPiGM4TztiiJ3vSzcCwnVu81DPI lh2d9pUlGurRN2mlpq9e3m5gYcm7MOVex7s9WJPAsqdZT+AKIH2QK88NirIvlGDyRpzT h5NtrN3jpDd7kGcvrDyLHdD0raTlKsarKH0+FbE7FFnmCaSUrUEeq6EF49UoaOvDnfq8 h20g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680195566; 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=q3Db68FKTl1xzxGqmcdObvg67qsPDOpji62Lx3fISMU=; b=LPYNrN2fIBwJ9FcsYGhy0UvrlvNNml94rMRZPVXFBlrt6Bt2nReXfuReNm/CgxB++V NAAPWuRg9h2LxdNzLDntSCedPsr/tC8Fehn8gwoBjsvOI88mYBuv2YVcov85dq8WF/Hm GUM2j59eXywpcpUi41CPbKdPXmAil2A8o3Focc5NHTzOanorR3tEkpyBsXNjQM9Ym0Tp sMWGMsW525o/7mY/Ap0aJpvTzbaVUPAvDb9IFq88RiHR6erzXwNhPjg7bAaD5vcH6gtN SKYh+irkNpZ+spICkYSLgQkNqNAJ/IbCOgACkF+7zctjH19cuDaRVAjgMphSk/6cUSg2 07jA== X-Gm-Message-State: AAQBX9ftUoS4qWlO/XUMCyhXtf/QIEzMJDkO/Z6ocHt5YB1/Gws//VPA ZMGQyymtH9lawK1gPE8tlWS9iXAFZa31edLu3bIelA== X-Google-Smtp-Source: AKy350a8gTj45t2QIadOduSRVh1B532ePgGn75Icp8kG7z6hArB7HZ0u8h8zfhjWDMty2mG3XOwP2I0BBB+uxwUhliQ= X-Received: by 2002:a5d:5243:0:b0:2cf:ec67:8f9f with SMTP id k3-20020a5d5243000000b002cfec678f9fmr4196413wrc.13.1680195566582; Thu, 30 Mar 2023 09:59:26 -0700 (PDT) MIME-Version: 1.0 References: <20230327080107.3266866-1-christoph.muellner@vrull.eu> <20230327080107.3266866-3-christoph.muellner@vrull.eu> <981c0ad5-3e84-d2f3-c14a-4c7bb70749a9@suse.com> <3fce7ece-855e-81dc-34fb-0953bc6e2ca7@suse.com> <293759bb-e66e-3ff1-c4d8-61f4fbee3d2c@suse.com> In-Reply-To: From: =?UTF-8?Q?Christoph_M=C3=BCllner?= Date: Thu, 30 Mar 2023 18:59:11 +0200 Message-ID: Subject: Re: [RFC PATCH v2 2/2] RISC-V: Add support for the Zfa extension To: Jan Beulich Cc: Kito Cheng , binutils@sourceware.org, Nelson Chu , Andrew Waterman , Palmer Dabbelt , Jim Wilson , Philipp Tomsich , Jeff Law , Tsukasa OI 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,KAM_SHORT,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: On Thu, Mar 30, 2023 at 6:13=E2=80=AFPM Jan Beulich wro= te: > > On 30.03.2023 17:36, Christoph M=C3=BCllner wrote: > > On Thu, Mar 30, 2023 at 2:18=E2=80=AFPM Jan Beulich = wrote: > >> > >> On 30.03.2023 12:54, Jan Beulich via Binutils wrote: > >>> On 30.03.2023 12:30, Christoph M=C3=BCllner wrote: > >>>> On Mon, Mar 27, 2023 at 11:54=E2=80=AFAM Jan Beulich wrote: > >>>>> > >>>>> On 27.03.2023 10:53, Kito Cheng wrote: > >>>>>> Wait, I mean the hex floating point format defined in C99/C++17, n= ot > >>>>>> the raw hex value. > >>>>>> so something like 0x1p-16 (0.0000152587890625), 0x1p-2 (0.25) 0x1p= +0, > >>>>>> -0x1p+0 could be used for fli.* instruction. > >>>>>> > >>>>>> You could use printf with %a to get those values. > >>>>>> > >>>>>> https://gcc.gnu.org/onlinedocs/gcc/Hex-Floats.html > >>>>>> https://developer.arm.com/documentation/dui0375/latest/Compiler-Co= ding-Practices/Hexadecimal-floating-point-numbers-in-C99 > >>>>> > >>>>> Sure, my (secondary) suggestion ... > >>>>> > >>>>>> On Mon, Mar 27, 2023 at 4:39=E2=80=AFPM Jan Beulich via Binutils > >>>>>> wrote: > >>>>>>> > >>>>>>> On 27.03.2023 10:01, Christoph Muellner wrote: > >>>>>>>> --- a/opcodes/riscv-opc.c > >>>>>>>> +++ b/opcodes/riscv-opc.c > >>>>>>>> @@ -110,6 +110,16 @@ const char * const riscv_vma[2] =3D > >>>>>>>> "mu", "ma" > >>>>>>>> }; > >>>>>>>> > >>>>>>>> +/* The FLI.[HSDQ] value constants. */ > >>>>>>>> +const char * const riscv_fli_value[32] =3D > >>>>>>>> +{ > >>>>>>>> + "-1.0", "min", "0.0000152587890625", "0.000030517578125", > >>>>>>>> + "0.00390625", "0.0078125", "0.0625", "0.125", > >>>>>>>> + "0.25", "0.3125", "0.375", "0.4375", "0.5", "0.625", "0.75", = "0.875", > >>>>>>>> + "1.0", "1.25", "1.5", "1.75", "2.0", "2.5", "3.0", "4.0", > >>>>>>>> + "8.0", "16.0", "128.0", "256.0", "32768.0", "65536.0", "inf"= , "nan", > >>>>>>>> +}; > >>>>>>> > >>>>>>> Especially for values like 1.0x2^^-n (entries 2 and onwards) I qu= estion > >>>>>>> the spelled out numbers to be the most suitable ones usability wi= se. At > >>>>>>> least some alternative spelling (e.g. 2.e-16) ought to be recogni= zed as > >>>>>>> well. But since there are meany reasonable spellings (leading 0 o= mitted > >>>>>>> in 0. or trailing zero omitted in .0), I guess I'd= prefer > >>>>>>> if values were actually parsed as a floating point number (e.g. v= ia > >>>>>>> ieee_md_atof()), and then matched against values stored in the ta= ble. > >>>>>>> One might further consider to also permit the 2nd form accepted > >>>>>>> elsewhere, see read.c:parse_one_float(). > >>>>> > >>>>> ... here wasn't meant to collide with yours. What you're asking for= is > >>>>> covered by my primary suggestion (to actually parse the values), ex= tended > >>>>> by the need to actually recognize C99 hex float in the parser then = (leaving > >>>>> aside for now whether that's feasible in the first place). > >>>> > >>>> Thanks for all the suggestions! > >>>> > >>>> I worked my way through this and I believe that the following would = be > >>>> a reasonable solution: > >>>> * constants min, inf and nan must be symbols (as stated in the speci= fication) > >>>> * other constants are parsed by scanf("%f") as floats and compared > >>>> (float compare in C) against the numeric constants in the table > >>>> * output in the disassembly uses symbols for min/inf/nan and %a (hex > >>>> FP literals) for other constants > >>>> > >>>> So we support every format that '%f' accepts including hex FP litera= ls > >>>> (e.g. -0x1p0, 0x1p+0, ...) and normal FP constants (e.g. > >>>> 0.0000152587890625, 25E-4). > >>> > >>> How's this going to work with a cross-assembler run on an architectur= e > >>> supporting a floating point format other than IEEE 754's? Hence why I > >>> suggested using ieee_md_atof() instead. > >> > >> Hmm, I see riscv_fli_numval[] has "float" as the base type (which I > >> didn't really expect), so this ought to work as long as the initialize= rs > >> used can be represented exactly in whatever arch's floating point form= at. > > > > The idea to compare parsed FP numbers was yours (thanks for that!). > > To do that the use of floats seemed obvious as I did not see why using = the > > atof-ieee machinery was necessary (I did not consider non IEEE 754 mach= ines). > > > > Since we only parse and compare, at least the hex FP literals should > > work on all machines (otherwise these machines would have more serious = issues). > > As I don't have access to non IEEE 754 machines I can not test other > > representations. > > > > I now had a look at the atof-ieee framework and found the following iss= ues: > > * ieee_md_atof() does not reveal the number of parsed bytes > > Workaround: use atof_ieee() directly instead (access to F_PRECISION w= ould > > be nice to not have to compare the whole LITTLENUM_TYPE values). > > * Parsing hex FP literals does not work > > Input: 0x1p-15 > > Error: Could not parse input: x1p-15 > > * Parsing two strings will always be slower than parsing only one of th= em. > > Why parsing two strings? The table values could all be pre-computed. Agree. > > > * Parsers in the atof-ieee framework don't care about pointer-to-const, > > but the constant tables are of type "const char * const". > > > > I now understand that the solution in this patch is not perfect. > > But given the alternative is not perfect either, I would prefer to > > keep the approach > > of this patch unless we identify that it is really broken on an > > existing machine that > > does not use IEEE 754 FP (we can add more test cases to spot that > > during testing). > > Fair enough I guess as long as it's properly spelled out somewhere, > so that people running into issues don't need to dig through half > the assembler. I just noticed that gas/doc/c-riscv.texi is missing a RISC-V Floating-point section. A new revision of this patch will include the information in there (including the error message that is expected on such a machine). Besides that I will also replace scanf() by strtof() in the new revision.