pair rv64imafdc with lp64, rt-thread want this

[lygstate]

Closes: #46

[ilg-ul]

Do you know why the existing pair with lp64d cannot be used?

[lygstate]

Do you know why the existing pair with lp64d cannot be used?

Rt-thread want to use lp64 for compiling the kernel(softfp )

Do you know why the existing pair with lp64d cannot be used?

c:/env-windows/tools/gnu_gcc/riscv64-linux-musleabi_for_i686-w64-mingw32/bin/../lib/gcc/riscv64-linux-musleabi/12.2.0/../../../../riscv64-linux-musleabi/bin/ld.exe: c:/env-windows/tools/gnu_gcc/riscv64-linux-musleabi_for_i686-w64-mingw32/bin/../lib/gcc/riscv64-linux-musleabi/12.2.0/../../../../riscv64-linux-musleabi/lib\libc_kernel.a(isxdigit.o): can't link soft-float modules with double-float modules

The toolchain are use target triple -march=rv64imafdc_zicsr_zifencei -mabi=lp64d compile musl, If I want to use xpack-riscv-gcc to replace the customized version riscv64-linux-musleabi_for_i686-w64-mingw32, then xpack-riscv-gcc should also support multilib -march=rv64imafdc_zicsr_zifencei -mabi=lp64d , this is for Enable RT-Thread Smart (microkernel on kernel/userland)",
as RT-Thread Smart are only running on rv64imafdc_zicsr_zifencei, so there is no need take care of non rv64imafdc_zicsr_zifencei target.

[lygstate]

Do you know why the existing pair with lp64d cannot be used?

in microkernel, soft-float should be used insead double-float

[ilg-ul]

Sorry, I don't get it.

The latest release already supports rv64imafdc_zicsr/lp64d;@march=rv64imafdc_zicsr@mabi=lp64d.

[ilg-ul]

in microkernel, soft-float should be used instead double-float

Ok, but can't you select soft-float when invoking the compiler?

[lygstate]

in microkernel, soft-float should be used instead double-float

Ok, but can't you select soft-float when invoking the compiler?

compiler is fine, but the libgcc are not, I need the multilib for libgcc

The latest release already supports rv64imafdc_zicsr/lp64d;@march=rv64imafdc_zicsr@mabi=lp64d

I want libgcc version rv64imafdc_zicsr/lp64;@march=rv64imafdc_zicsr@mabi=lp64

Therse files only have lp64d version, do not have lp64 version

 Directory of C:\env-windows\tools\gnu_gcc\xpack-riscv-none-elf-gcc-12.3.0-2\lib\gcc\riscv-none-elf\12.3.0\rv64imafdc_zicsr\lp64d

2023/09/22  13:27    <DIR>          .
2023/09/22  13:27    <DIR>          ..
2023/09/22  13:27             3,832 crtbegin.o
2023/09/22  13:27             1,160 crtend.o
2023/09/22  13:27               832 crti.o
2023/09/22  13:27               832 crtn.o
2023/09/22  13:27    <DIR>          finclude
2023/09/22  13:27           110,202 libcaf_single.a
2023/09/22  13:27         4,044,864 libgcc.a
2023/09/22  13:27         1,033,232 libgcov.a
               7 File(s)      5,194,954 bytes
               3 Dir(s)  1,419,142,459,392 bytes free

C:\env-windows\tools\gnu_gcc\xpack-riscv-none-elf-gcc-12.3.0-2\lib\gcc\riscv-none-elf\12.3.0\rv64imafdc_zicsr\lp64d>

[ilg-ul]

I'm reluctant to add new multilibs, since this increases the archive size and the build time.

[lygstate]

I'm reluctant to add new multilibs, since this increases the archive size and the build time.

This is the most generic and wanted version, rv64imafdc means rv64gc, I am not request for rarely used version

[ilg-ul]

These files only have lp64d version, do not have lp64 version

Are you sure those files really include hard float code? Did you try using them and had any issues?

[lygstate]

These files only have lp64d version, do not have lp64 version

Are you sure those files really include hard float code? Did you try using them and had any issues?

It's compiler internal, not safe use it, there will be ABI mismatch issue, this is the issue demo:

c:/env-windows/tools/gnu_gcc/riscv64-linux-musleabi_for_i686-w64-mingw32/bin/../lib/gcc/riscv64-linux-musleabi/12.2.0/../../../../riscv64-linux-musleabi/bin/ld.exe: c:/env-windows/tools/gnu_gcc/riscv64-linux-musleabi_for_i686-w64-mingw32/bin/../lib/gcc/riscv64-linux-musleabi/12.2.0/../../../../riscv64-linux-musleabi/lib\libc_kernel.a(isxdigit.o): can't link soft-float modules with double-float modules

[ilg-ul]

If you want to fully avoid hard float, why not use rv64imac/lp64;@march=rv64imac@mabi=lp64?

[lygstate]

If you want to fully avoid hard float, why not use rv64imac/lp64;@march=rv64imac@mabi=lp64?

Only ABI need to be lp64

AS build\kernel\components\lwp\arch\risc-v\rv64\lwp_gcc.o                                                                                                               
C:\work\acrop\rt-thread\components\lwp\arch\risc-v\rv64\lwp_gcc.S: Assembler messages:                                                                                  
C:\work\acrop\rt-thread\components\lwp\arch\risc-v\rv64\lwp_gcc.S:107: Error: unrecognized opcode `fld f0,(8*0)(t2)', extension `d' required                            
C:\work\acrop\rt-thread\components\lwp\arch\risc-v\rv64\lwp_gcc.S:107: Error: unrecognized opcode `fld f1,(8*1)(t2)', extension `d' required                            
C:\work\acrop\rt-thread\components\lwp\arch\risc-v\rv64\lwp_gcc.S:107: Error: unrecognized opcode `fld f2,(8*2)(t2)', extension `d' required                            
C:\work\acrop\rt-thread\components\lwp\arch\risc-v\rv64\lwp_gcc.S:107: Error: unrecognized opcode `fld f3,(8*3)(t2)', extension `d' required                            
C:\work\acrop\rt-thread\components\lwp\arch\risc-v\rv64\lwp_gcc.S:107: Error: unrecognized opcode `fld f4,(8*4)(t2)', extension `d' required                            
C:\work\acrop\rt-thread\components\lwp\arch\risc-v\rv64\lwp_gcc.S:107: Error: unrecognized opcode `fld f5,(8*5)(t2)', extension `d' required                            
C:\work\acrop\rt-thread\components\lwp\arch\risc-v\rv64\lwp_gcc.S:107: Error: unrecognized opcode `fld f6,(8*6)(t2)', extension `d' required                            
C:\work\acrop\rt-thread\components\lwp\arch\risc-v\rv64\lwp_gcc.S:107: Error: unrecognized opcode `fld f7,(8*7)(t2)', extension `d' required                            
C:\work\acrop\rt-thread\components\lwp\arch\risc-v\rv64\lwp_gcc.S:107: Error: unrecognized opcode `fld f8,(8*8)(t2)', extension `d' required                            
C:\work\acrop\rt-thread\components\lwp\arch\risc-v\rv64\lwp_gcc.S:107: Error: unrecognized opcode `fld f9,(8*9)(t2)', extension `d' required                            
C:\work\acrop\rt-thread\components\lwp\arch\risc-v\rv64\lwp_gcc.S:107: Error: unrecognized opcode `fld f10,(8*10)(t2)', extension `d' required                          
C:\work\acrop\rt-thread\components\lwp\arch\risc-v\rv64\lwp_gcc.S:107: Error: unrecognized opcode `fld f11,(8*11)(t2)', extension `d' required                          
C:\work\acrop\rt-thread\components\lwp\arch\risc-v\rv64\lwp_gcc.S:107: Error: unrecognized opcode `fld f12,(8*12)(t2)', extension `d' required                          
C:\work\acrop\rt-thread\components\lwp\arch\risc-v\rv64\lwp_gcc.S:107: Error: unrecognized opcode `fld f13,(8*13)(t2)', extension `d' required                          
C:\work\acrop\rt-thread\components\lwp\arch\risc-v\rv64\lwp_gcc.S:107: Error: unrecognized opcode `fld f14,(8*14)(t2)', extension `d' required                          
C:\work\acrop\rt-thread\components\lwp\arch\risc-v\rv64\lwp_gcc.S:107: Error: unrecognized opcode `fld f15,(8*15)(t2)', extension `d' required                          
C:\work\acrop\rt-thread\components\lwp\arch\risc-v\rv64\lwp_gcc.S:107: Error: unrecognized opcode `fld f16,(8*16)(t2)', extension `d' required                          
C:\work\acrop\rt-thread\components\lwp\arch\risc-v\rv64\lwp_gcc.S:107: Error: unrecognized opcode `fld f17,(8*17)(t2)', extension `d' required                          
C:\work\acrop\rt-thread\components\lwp\arch\risc-v\rv64\lwp_gcc.S:107: Error: unrecognized opcode `fld f18,(8*18)(t2)', extension `d' required                          
C:\work\acrop\rt-thread\components\lwp\arch\risc-v\rv64\lwp_gcc.S:107: Error: unrecognized opcode `fld f19,(8*19)(t2)', extension `d' required                          
C:\work\acrop\rt-thread\components\lwp\arch\risc-v\rv64\lwp_gcc.S:107: Error: unrecognized opcode `fld f20,(8*20)(t2)', extension `d' required                          
C:\work\acrop\rt-thread\components\lwp\arch\risc-v\rv64\lwp_gcc.S:107: Error: unrecognized opcode `fld f21,(8*21)(t2)', extension `d' required                          
C:\work\acrop\rt-thread\components\lwp\arch\risc-v\rv64\lwp_gcc.S:107: Error: unrecognized opcode `fld f22,(8*22)(t2)', extension `d' required                          
C:\work\acrop\rt-thread\components\lwp\arch\risc-v\rv64\lwp_gcc.S:107: Error: unrecognized opcode `fld f23,(8*23)(t2)', extension `d' required                          
C:\work\acrop\rt-thread\components\lwp\arch\risc-v\rv64\lwp_gcc.S:107: Error: unrecognized opcode `fld f24,(8*24)(t2)', extension `d' required                          
C:\work\acrop\rt-thread\components\lwp\arch\risc-v\rv64\lwp_gcc.S:107: Error: unrecognized opcode `fld f25,(8*25)(t2)', extension `d' required                          
C:\work\acrop\rt-thread\components\lwp\arch\risc-v\rv64\lwp_gcc.S:107: Error: unrecognized opcode `fld f26,(8*26)(t2)', extension `d' required                          
C:\work\acrop\rt-thread\components\lwp\arch\risc-v\rv64\lwp_gcc.S:107: Error: unrecognized opcode `fld f27,(8*27)(t2)', extension `d' required                          
C:\work\acrop\rt-thread\components\lwp\arch\risc-v\rv64\lwp_gcc.S:107: Error: unrecognized opcode `fld f28,(8*28)(t2)', extension `d' required                          
C:\work\acrop\rt-thread\components\lwp\arch\risc-v\rv64\lwp_gcc.S:107: Error: unrecognized opcode `fld f29,(8*29)(t2)', extension `d' required                          
C:\work\acrop\rt-thread\components\lwp\arch\risc-v\rv64\lwp_gcc.S:107: Error: unrecognized opcode `fld f30,(8*30)(t2)', extension `d' required                          
C:\work\acrop\rt-thread\components\lwp\arch\risc-v\rv64\lwp_gcc.S:107: Error: unrecognized opcode `fld f31,(8*31)(t2)', extension `d' required                          

[ilg-ul]

In my opinion this is an unusual configuration. Probably it is better to use the official toolchain recommended by rt-threads.

[lygstate]

In my opinion this is an unusual configuration. Probably it is better to use the official toolchain recommended by rt-threads.

It's very usefull, rt-thread have many user, just because xpack do not have this configuration, so rt-thread have to compiled a custom version

https://github.com/RT-Thread/rt-thread.git have 11.k stars

[ilg-ul]

They might be successful, but if they rely on custom toolchains, something is not right with the design.

[TommyMurphyTM1234]

I agree with @ilg-ul - the use of rv64gc/lp64 (aka rv64imafdc/lp64) where the code base includes assembly language files using D extension instructions seems very odd. If the target supports - and some of the code uses! - hardware floating point instructions then it seems suboptimal to not use them fully/globally. And if they are used then it seems logical to use the ABI that matches their use - i.e. lp64d. What is the rationale for not doing this?

[lygstate]

I agree with @ilg-ul - the use of rv64gc/lp64 (aka rv64imafdc/lp64) where the code base includes assembly language files using D extension instructions seems very odd. If the target supports - and some of the code uses! - hardware floating point instructions then it seems suboptimal to not use them fully/globally. And if they are used then it seems logical to use the ABI that matches their use - i.e. lp64d. What is the rationale for not doing this?

It's all about the mciro-kernel, use lp64 ABI will avoid saving the float registers when switch between usermode and kernelmode

[TommyMurphyTM1234]

What if assembly language files that explicitly use floating point instructions (such as mentioned here) are compiled with -march=rv64gc -mabi=lp64 (or maybe -march=rv64gc -mabi=lp64d?) and everything else including the link phase uses -march=rv64imac -mabi=lp64? Might that work?

[lygstate]

What if assembly language files that explicitly use floating point instructions (such as mentioned here) are compiled with -march=rv64gc -mabi=lp64 (or maybe -march=rv64gc -mabi=lp64d?) and everything else including the link phase uses -march=rv64imac -mabi=lp64? Might that work?

that's very complicated softfp abi is a very useful

[TommyMurphyTM1234]

that's very complicated

I don't think it's that complicated. Simply a tweaking of the Makefile/build scripts worth trying to see if the existing toolchain options and aech/abi support are adequate.

softfp abi is a very useful

And arguably most appropriate where there is no support for, or use of, hard floating point extensions such as D.

[ilg-ul]

My experience with various RISC-V ABIs is poor, I'm using RISC-V only to run some unit tests on rm32imac and rv64imafdc and everything is fine. I plan to fully port my µOS++ to RISC-V 32/64 and by that time I'll know more about this.

For now I'm afraid this PR will not be merged.

[TommyMurphyTM1234]

My experience with various RISC-V ABIs is poor

Do you mean "limited" or that you've had bad experiences?

[ilg-ul]

I ment limited, but, if you remember the long arguments I had in the early years with the Berkeley team about the need of an embedded ABI, the experience wasn't good either.