[6/9] RISC-V: Split the soft-fp into rv32 and rv64

Message ID 7556c9af67290455145fd92e621439c7cc2e8f48.1531384754.git.zong@andestech.com
State New
Headers show
Series
  • RISC-V glibc port for the 32 bit
Related show

Commit Message

Zong Li July 12, 2018, 10:26 a.m.
The soft-fp not support long double calculation on 32 bit.
There are losing some implementation in soft-fp/op-8.h now.
So we let 32 bit use ldbl-128 first for some emulation such
as fmal and so on. It can be merged after the long double support.
---
 sysdeps/riscv/nofpu/Implies      | 1 -
 sysdeps/riscv/rv32/nofpu/Implies | 2 ++
 sysdeps/riscv/rv64/nofpu/Implies | 1 +
 3 files changed, 3 insertions(+), 1 deletion(-)
 delete mode 100644 sysdeps/riscv/nofpu/Implies
 create mode 100644 sysdeps/riscv/rv32/nofpu/Implies
 create mode 100644 sysdeps/riscv/rv64/nofpu/Implies

Comments

Richard Henderson July 12, 2018, 5:46 p.m. | #1
On 07/12/2018 05:26 AM, Zong Li wrote:
> The soft-fp not support long double calculation on 32 bit.

The generic soft-fp implementation certainly does support ieee128 on a 32-bit
host.  You probably have misconfigured sfp-machine.h.

What problem are you encountering?


r~
Zong Li July 13, 2018, 1 a.m. | #2
Richard Henderson <rth@twiddle.net> 於 2018年7月13日 週五 上午1:46寫道:
>
> On 07/12/2018 05:26 AM, Zong Li wrote:
> > The soft-fp not support long double calculation on 32 bit.
>
> The generic soft-fp implementation certainly does support ieee128 on a 32-bit
> host.  You probably have misconfigured sfp-machine.h.
>
> What problem are you encountering?
>
>
> r~

Hi Richard,

I encountered some macro were not defined. This is one of my cases.
When I built the soft-fp/s_fmal.c, there uses the FP_FMA_Q in __fmal.
I define the _FP_W_TYPE_SIZE is 32 in sysdeps/riscv/sfp-machine.h,
so the FP_FMA_Q was defined to _FP_FMA (Q, 4, 8, R, X, Y, Z) in soft-fp/quad.h.

Something in the soft-fp/quad.h:
#if _FP_W_TYPE_SIZE < 64
    # define FP_FMA_Q(R, X, Y, Z)    _FP_FMA (Q, 4, 8, R, X, Y, Z)
#else
    # define FP_FMA_Q(R, X, Y, Z)    _FP_FMA (Q, 2, 4, R, X, Y, Z)
#endif

This is the problem I encountered, In  _FP_FMA (fs, wc, dwc, R, X, Y, Z),
it will use the _FP_FRAC_HIGHBIT_DW_##dwc macro, and it will be expanded to
 _FP_FRAC_HIGHBIT_DW_8, but the _FP_FRAC_HIGHBIT_DW_8 is not be
implemented in soft-fp/op-8.h, there is only _FP_FRAC_HIGHBIT_DW_1,
_FP_FRAC_HIGHBIT_DW_2 and _FP_FRAC_HIGHBIT_DW_4 in the soft-fp/op-*.h.

I cannot find another 32 bit port has this issue, because they use the ldbl-128.

Did I miss something here?
Richard Henderson July 13, 2018, 10:34 a.m. | #3
On 07/12/2018 08:00 PM, Zong Li wrote:
> This is the problem I encountered, In  _FP_FMA (fs, wc, dwc, R, X, Y, Z),
> it will use the _FP_FRAC_HIGHBIT_DW_##dwc macro, and it will be expanded to
>  _FP_FRAC_HIGHBIT_DW_8, but the _FP_FRAC_HIGHBIT_DW_8 is not be
> implemented in soft-fp/op-8.h, there is only _FP_FRAC_HIGHBIT_DW_1,
> _FP_FRAC_HIGHBIT_DW_2 and _FP_FRAC_HIGHBIT_DW_4 in the soft-fp/op-*.h.
> 
> I cannot find another 32 bit port has this issue, because they use the ldbl-128.

It appears that the code has bitrotted somewhat because of non-use.

Also, _FP_FRAC_HIGHBIT_DW_[1234] is a macro that should not exist,
because it has an identical definition in each case.  But in the
meantime, just copy any of the other (identical) definitions into
op-8.h.

The other levels of macro nesting to which this expands does exist.
At least as far as I can track it by eye.  ;-)


r~
Zong Li July 13, 2018, 1:19 p.m. | #4
Richard Henderson <rth@twiddle.net> 於 2018年7月13日 週五 下午6:34寫道:
>
> On 07/12/2018 08:00 PM, Zong Li wrote:
> > This is the problem I encountered, In  _FP_FMA (fs, wc, dwc, R, X, Y, Z),
> > it will use the _FP_FRAC_HIGHBIT_DW_##dwc macro, and it will be expanded to
> >  _FP_FRAC_HIGHBIT_DW_8, but the _FP_FRAC_HIGHBIT_DW_8 is not be
> > implemented in soft-fp/op-8.h, there is only _FP_FRAC_HIGHBIT_DW_1,
> > _FP_FRAC_HIGHBIT_DW_2 and _FP_FRAC_HIGHBIT_DW_4 in the soft-fp/op-*.h.
> >
> > I cannot find another 32 bit port has this issue, because they use the ldbl-128.
>
> It appears that the code has bitrotted somewhat because of non-use.
>
> Also, _FP_FRAC_HIGHBIT_DW_[1234] is a macro that should not exist,
> because it has an identical definition in each case.  But in the
> meantime, just copy any of the other (identical) definitions into
> op-8.h.
>
> The other levels of macro nesting to which this expands does exist.
> At least as far as I can track it by eye.  ;-)
>
>
> r~

Thanks for your reply. So shall I need to submit a patch for adding
these definition of
macros first?
Richard Henderson July 13, 2018, 1:49 p.m. | #5
On 07/13/2018 08:19 AM, Zong Li wrote:
> Thanks for your reply. So shall I need to submit a patch for adding
> these definition of
> macros first?

Or include them in your patch set, yes.


r~
Zong Li July 13, 2018, 1:54 p.m. | #6
Richard Henderson <rth@twiddle.net> 於 2018年7月13日 週五 下午9:49寫道:
>
> On 07/13/2018 08:19 AM, Zong Li wrote:
> > Thanks for your reply. So shall I need to submit a patch for adding
> > these definition of
> > macros first?
>
> Or include them in your patch set, yes.
>
>
> r~
>
OK, I see. Thanks for your help.

Patch

diff --git a/sysdeps/riscv/nofpu/Implies b/sysdeps/riscv/nofpu/Implies
deleted file mode 100644
index abcbadb..0000000
--- a/sysdeps/riscv/nofpu/Implies
+++ /dev/null
@@ -1 +0,0 @@ 
-ieee754/soft-fp
diff --git a/sysdeps/riscv/rv32/nofpu/Implies b/sysdeps/riscv/rv32/nofpu/Implies
new file mode 100644
index 0000000..603ee88
--- /dev/null
+++ b/sysdeps/riscv/rv32/nofpu/Implies
@@ -0,0 +1,2 @@ 
+ieee754/ldbl-128
+ieee754/soft-fp
diff --git a/sysdeps/riscv/rv64/nofpu/Implies b/sysdeps/riscv/rv64/nofpu/Implies
new file mode 100644
index 0000000..abcbadb
--- /dev/null
+++ b/sysdeps/riscv/rv64/nofpu/Implies
@@ -0,0 +1 @@ 
+ieee754/soft-fp