[RFC PATCH v2 2/2] RISC-V: Add support for the Zfa extension

[Jan Beulich]

On 27.03.2023 10:53, Kito Cheng wrote:
> Wait, I mean the hex floating point format defined in C99/C++17, not
> 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-Coding-Practices/Hexadecimal-floating-point-numbers-in-C99

Sure, my (secondary) suggestion ...

> On Mon, Mar 27, 2023 at 4:39 PM Jan Beulich via Binutils
> <binutils@sourceware.org> 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] =
>>>    "mu", "ma"
>>>  };
>>>
>>> +/* The FLI.[HSDQ] value constants.  */
>>> +const char * const riscv_fli_value[32] =
>>> +{
>>> +  "-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 question
>> the spelled out numbers to be the most suitable ones usability wise. At
>> least some alternative spelling (e.g. 2.e-16) ought to be recognized as
>> well. But since there are meany reasonable spellings (leading 0 omitted
>> in 0.<fraction> or trailing zero omitted in <num>.0), I guess I'd prefer
>> if values were actually parsed as a floating point number (e.g. via
>> ieee_md_atof()), and then matched against values stored in the table.
>> 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), extended
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).

Jan