Re: [PATCH 0/1] RISC-V: Fix RV32Q conflict

[Tsukasa OI <research_trasio@irq.a4lg.com>]

On 2022/02/07 16:48, Jan Beulich wrote:
> On 07.02.2022 04:31, Tsukasa OI via Binutils wrote:
>> This commit allows combination of RV32 + 'Q' extension (IEEE 754
>> binary128 floating point number support).
>>
>> This combination is no longer prohibited by the ISA Manual.
>>
>> This restriction is introduced in binutils' RV32E support commit
>> 7f99954970001cfc1b155d877ac2966d77e2c647.  At that time,
>> the latest ratified version of the RISC-V ISA Manual (version 2.2)
>> stated that 'Q' extension requires RV64IFD.
>>
>> However, the next ratified version of the RISC-V ISA Manual
>> (20190608-Base-Ratified) removed such limitation.
> 
> Ah yes, one of the anomalies I did notice a while ago and didn't get
> around to writing mail about, yet. A related anomaly looks to be that
> RV32E excludes F, without me being able to find respective wording in
> the spec.

ISA Manual, version 2.2 (3.3. RV32E Extensions):
> RV32E can be extended with the M, A, and C user-level standard
> extensions.

Yes, it prohibits (not only but including) F standard extension.

ISA Manual, version 20190608-Base-Ratified (4.2. RV32E Instruction Set):
> RV32E can be combined with all current standard extensions. Defining
> the F, D, and Q extensions as having a 16-entry floating point
> register file when combined with RV32E was considered but decided
> against. To support systems with reduced floating-point register
> state, we intend to define a “Zfinx” extension (...cont...)

It seems...  not intended but not directly prohibited either?

Still, there is an ABI conflict between RV32E and use of floating point
registers so (even if not prohibited) it wouldn't be the same as this
patchset (cf. riscv_set_abi_by_arch function in gas/config/tc-riscv.c).

Tsukasa

> 
> Jan
> 
>> I did check the version of 'Q' extension (RV32Q is allowed on 'Q'
>> extension version 2.2 or later) but it may be too pedant.
>>
>> This is because  change (removal of RV64IFD dependency) seemed irrevant
>> to version changes but only a part of "embellishment" process as
>> described by riscv-isa-manual commit
>> 013ba6dc8a504ee4ad7bee42554fecaef7ba797f.
>>
>> Quoting preface of 20190608-Base-Ratified (would analogously to 'Q'),
>>
>>> Incremented the version numbers of the F and D extensions to 2.2,
>>> reflecting that version 2.1 changed the canonical NaN, and version 2.2
>>> defined the NaN-boxing scheme and changed the definition of the FMIN
>>> and FMAX instructions.
>>
>> Not checking the version number (just allowing RV32Q entirely) may be
>> an option.
>>
>>
>> References:
>>
>> GNU Binutils:
>>   Commit 7f99954970001cfc1b155d877ac2966d77e2c647
>>     <https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=7f99954970001cfc1b155d877ac2966d77e2c647>
>>
>> The RISC-V ISA Manual:
>>   version 2.2
>>     <https://github.com/riscv/riscv-isa-manual/releases?q=2.2>
>>   version 20190608-Base-Ratified
>>     <https://github.com/riscv/riscv-isa-manual/releases?q=Ratified-IMFDQC-and-Priv-v1.11>
>>   commit 013ba6dc8a504ee4ad7bee42554fecaef7ba797f:
>>     <https://github.com/riscv/riscv-isa-manual/commit/013ba6dc8a504ee4ad7bee42554fecaef7ba797f>
>>
>>
>>
>>
>> Tsukasa OI (1):
>>   RISC-V: Fix RV32Q conflict
>>
>>  bfd/elfxx-riscv.c | 5 +++--
>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>
>>
>> base-commit: 6a9d08661b361e497baa76dd6d8685f2cb593adb
>