mbox series

[RFC,0/6] softfloat 128-bit integer support

Message ID 20220328201442.175206-1-matheus.ferst@eldorado.org.br (mailing list archive)
Headers show
Series softfloat 128-bit integer support | expand

Message

Matheus K. Ferst March 28, 2022, 8:14 p.m. UTC
From: Matheus Ferst <matheus.ferst@eldorado.org.br>

This RFC is a first attempt at implementing the 128-bit integer
conversion routines in softfloat, as required by the xscv[su]qqp and
xscvqp[su]qz instructions of PowerISA v3.1.

Instead of using int128.h, int-to-float routines receive the 128-bit
numbers through a pair of 64-bit values, and float-to-int conversions
use a pointer to return the lower half of the result.

We only need the parts128 methods, but since the difference to parts64
ones seemed minor, I included both in this patch.

RFC:
 - Should we use struct Int128 instead of 64-bit value pairs?
 - I've not tested the float64 methods since the PPC instructions only
   use the quad-precision routines. Should we keep them in the final
   version?

Matheus Ferst (6):
  softfloat: add uint128_to_float* conversion methods
  softfloat: add int128_to_float* conversion methods
  softfloat: add float*_to_uint128 conversion methods
  softfloat: add float*_to_int128 conversion methods
  target/ppc: implement xscv[su]qqp
  target/ppc: implement xscvqp[su]qz

 fpu/softfloat-parts.c.inc           | 202 ++++++++++++++++++++++++++++
 fpu/softfloat.c                     | 161 ++++++++++++++++++++++
 include/fpu/softfloat.h             |  23 ++++
 target/ppc/fpu_helper.c             |  34 +++++
 target/ppc/helper.h                 |   4 +
 target/ppc/insn32.decode            |   7 +
 target/ppc/translate/vsx-impl.c.inc |  22 +++
 7 files changed, 453 insertions(+)

Comments

Richard Henderson March 29, 2022, 3:38 a.m. UTC | #1
On 3/28/22 14:14, matheus.ferst@eldorado.org.br wrote:
> From: Matheus Ferst <matheus.ferst@eldorado.org.br>
> 
> This RFC is a first attempt at implementing the 128-bit integer
> conversion routines in softfloat, as required by the xscv[su]qqp and
> xscvqp[su]qz instructions of PowerISA v3.1.
> 
> Instead of using int128.h, int-to-float routines receive the 128-bit
> numbers through a pair of 64-bit values, and float-to-int conversions
> use a pointer to return the lower half of the result.
> 
> We only need the parts128 methods, but since the difference to parts64
> ones seemed minor, I included both in this patch.
> 
> RFC:
>   - Should we use struct Int128 instead of 64-bit value pairs?

I think so.  We have it, and it makes the interface more obvious.

>   - I've not tested the float64 methods since the PPC instructions only
>     use the quad-precision routines. Should we keep them in the final
>     version?

Let's not add anything that we don't have a need for.
It may eventually be needed by RISC-V RV128, but we can add it then.


r~
Matheus K. Ferst March 30, 2022, 5:59 p.m. UTC | #2
On 29/03/2022 00:38, Richard Henderson wrote:
> On 3/28/22 14:14, matheus.ferst@eldorado.org.br wrote:
>> From: Matheus Ferst <matheus.ferst@eldorado.org.br>
>>
>> This RFC is a first attempt at implementing the 128-bit integer
>> conversion routines in softfloat, as required by the xscv[su]qqp and
>> xscvqp[su]qz instructions of PowerISA v3.1.
>>
>> Instead of using int128.h, int-to-float routines receive the 128-bit
>> numbers through a pair of 64-bit values, and float-to-int conversions
>> use a pointer to return the lower half of the result.
>>
>> We only need the parts128 methods, but since the difference to parts64
>> ones seemed minor, I included both in this patch.
>>
>> RFC:
>>   - Should we use struct Int128 instead of 64-bit value pairs?
> 
> I think so.  We have it, and it makes the interface more obvious.
> 
>>   - I've not tested the float64 methods since the PPC instructions only
>>     use the quad-precision routines. Should we keep them in the final
>>     version?
> 
> Let's not add anything that we don't have a need for.
> It may eventually be needed by RISC-V RV128, but we can add it then.
> 
> 
> r~

Thanks for your comments and review. I'll send an alternative version of 
this RFC using Int128.