Hello! I can't assist with RISC-V, but let me know if you have any trouble with https://gitlab.haskell.org. In particular, approving accounts is currently a manual process. When you create an account, let me know the username, and I will approve it. Best wishes, -Bryan On Thu, 8 Jun 2023 at 14:42, Moritz Angermann wrote:

Hi Shiwei,

Let me try to draw up a more visual representation do the current pipelines over the weekend. That might also explain why I think the subset might work as the intermediate steps *do* carry register width.

Cheers, Moritz

On Thu, 8 Jun 2023 at 2:44 PM, 卢诗炜 wrote:

...

Moritz,

Thank you for your detailed response. However, we think that RV32 is not a subset of RV64, and that the instruction selection logic for RV32 and RV64 may differ. Because RV32 and RV64 have different register widths, it is sometimes necessary to use different instructions than RV64 to ensure correct results.

We plan to support RV32 in Native Code Generation. And we may draw inspiration from your support for RV64. We do want to be able to support RV32I+MAF, also include C extensions.

Do you have any comments or suggestions?

Thank you so much for your answer and help!

Best regards， Shiwei

卢诗炜 shiwei.lu@compiler-dev.com

https://lingxi.office.163.com/static_html/signature.html?id=69484630301586661&show= 签名由 网易灵犀办公 https://hubble.netease.com/sl/aaagLd 定制

Original:

- From：moritz.angermann - Date：2023-06-08 09:59:38(中国(GMT+08:00))

- To：卢诗炜 - Cc： - Subject：Re: Inquiry about Supporting RISC-V 32 in Haskell

诗炜,

This is a bit hard to answer. As GHC is a fairly distributed open source project, everyone can effectively just contribute (by opening a Merge Request on gitlab.haskell.org/ghc), and then the discussion around it will start. There is no fixed plan as to what ends up in e.g. GHC 9.8 (merge window will close June 16th), or even what GHC 9.10 will look like or when it will be release (likely the merge window will close mid December).

GHC has various ways to generate code: - Via a C backend (compile Haskell to C, use a C compiler to compile to machine code). This backend is quite slow (compile time, and runtime) - Via LLVM (comile Haskell to LLVM textual IR, then use LLVM's `opt` and `llc` to compile it to machine code). This backend produces good performing code, but is very slow to compile. - Via Native Code Generation (this turns Haskell into assembly, and then uses usually the CC compiler to just turn .S into .o). This has good compile time performance, and often competitive runtime performance. However this lacks for all supposed architectures proper SIMD support.

The LLVM backend can _in theory_ compile to any LLVM supported target. (The LLVM RV64 backend in GHC is that effectively). The Native Code Generator (NCG), support x86_64, i686, aarch64, and soon rv64. There are also powerpc, sparc and mips NCG backends, however the state of most cross compilation targets are only on a best effort basis and are not tested in CI. Since GHC 9.2 there are also JavaScript and WASM backends in GHC.

If you just want to cross compile for RV32, going down the LLVM route might be the easiest.

_my_ current plans are to work on - The RV64 NCG - The linker/loader for ELF/RV64 - aarch32 NCG

For RV32, we are in the lucky position that the instruction set is effectively just a subset of the RV64 instruction set. So we might be able to request some of the RV64 backend, or even better make the RV64 backend a superset of the RV32 backend.

I assume you are looking to support RV32I+MAF?

Happy to help with any follow up questions.

Cheers, Moritz

On Thu, 8 Jun 2023 at 08:38, 卢诗炜 wrote:

...

Thank you for your prompt reply. We have seen the support for your team working for RV64 in the GHC. You've done a great job.

We'd like to do what your team does for GHC by supporting new compile backends, like RV32, to contribute to the community. We are more focused on _cross compilation_ from x86_64 to RV32 on Linux. But we dont know much about GHC's current dynamics and plans, whether there is a need for this or whether support is being provided.

Do we need to support RV32 for GHC? Or is there anything else you think we can contribute to?

Looking forward to your reply, Thanks!

Best regards， Shiwei

卢诗炜 shiwei.lu@compiler-dev.com

https://lingxi.office.163.com/static_html/signature.html?id=69484630301586661&show= 签名由 网易灵犀办公 https://hubble.netease.com/sl/aaagLd 定制

Original:

- From：moritz.angermann - Date：2023-06-07 19:45:32 - To：卢诗炜 - Cc： - Subject：Re: Inquiry about Supporting RISC-V 32 in Haskell

您好诗炜！ 对不起，我的中文不很好。写英语。 I assume you've found my email from the ghc source repo? Yes, I have extensive experience adding compiler backends to GHC, including GHC's internal static linker. Recently a friend and I have started working on RV64 support in GHC (See https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10367). So we have some prior experience with RISC-V.

I understand you want to have support for RV32 in ghc? Are you looking for _native_ RV32 support GHC the compiler running natively on RISC-V 32 hardware? Or are you primarily interested in _cross compilation_ to RV32 from e.g. RV64, x86_64, aarch64?

Also which platform are you interested in? Linux?

Happy to provide more concrete feedback based on your exact requirements and vision. Ultimately GHC is a community project and everyone can contribute. I can certainly provide guidance and assistance here.

Cheers, Moritz

On Wed, 7 Jun 2023 at 18:16, 卢诗炜 wrote:

...

Dear Moritz Angermann，

Hello! I am writing on behalf of Hunan Compiler Technology Co., Ltd. to inquire about the possibility of supporting RISC-V 32 in Haskell o

r if you're supporting it . We are a technology company based in China and we would like to contribute to the Haskell community by providing support for this architecture.

As you may know, RISC-V is an open-source instruction set architecture that is gaining popularity in the industry. It is important for us to ensure that our products are compatible with this architecture, and we believe that supporting RISC-V in Haskell would be a valuable contribution to the community.

We are willing to work closely with the community to understand the requirements and challenges of supporting RISC-V in Haskell. We have a team of experienced engineers who are familiar with both Haskell and RISC-V, and we are confident that we can provide high-quality support for this architecture.

We would appreciate any guidance or feedback from the community on this matter. Please let us know if there are any specific requirements or challenges that we should be aware of. We look forward to working with the Haskell community to support RISC-V.

Thank you for your time and consideration.

Sincerely, Shiwei LU, Hunan Compiler Technology Co., Ltd.

https://lingxi.office.163.com/static_html/signature.html?id=69484630301586661&show=

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Hi Shiwei,

Let me try to draw up a more visual representation do the current pipelines over the weekend. That might also explain why I think the subset might work as the intermediate steps *do* carry register width.

Cheers, Moritz

On Thu, 8 Jun 2023 at 2:44 PM, 卢诗炜 wrote:

...

Moritz,

Thank you for your detailed response. However, we think that RV32 is not a subset of RV64, and that the instruction selection logic for RV32 and RV64 may differ. Because RV32 and RV64 have different register widths, it is sometimes necessary to use different instructions than RV64 to ensure correct results.

We plan to support RV32 in Native Code Generation. And we may draw inspiration from your support for RV64. We do want to be able to support RV32I+MAF, also include C extensions.

Do you have any comments or suggestions?

For what it's worth, I generally agree with MOritz that it should be

Moritz Angermann writes: possible for one RISC-V NCG backend to handle both RV32 and RV64. While it's true that RV32 may not be a strict subset of RV64, it is similar enough that it should be possible to work. For instance, the same approach is used within GHC to handle x86-64 and i386; in that case the NCG implementation is quite maintainable despite the rather considerable differences between the two ISAs. Cheers, - Ben