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, 卢诗炜 <shiwei...@compiler-dev.com> 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...@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<moritz.angerm...@gmail.com> > - Date：2023-06-08 09:59:38(中国(GMT+08:00)) > > > - To：卢诗炜<shiwei...@compiler-dev.com> > - 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, 卢诗炜 <shiwei...@compiler-dev.com> 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...@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<moritz.angerm...@gmail.com> >> - Date：2023-06-07 19:45:32 >> - To：卢诗炜<shiwei...@compiler-dev.com> >> - 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, 卢诗炜 <shiwei...@compiler-dev.com> 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
