Inquiry about Supporting RISC-V 32 in Haskell

Wed Jun 14 12:58:45 UTC 2023

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 <moritz.angermann at gmail.com>
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, 卢诗炜 <shiwei.lu at 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.lu at 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.angermann at gmail.com>
>>    - Date：2023-06-08 09:59:38(中国(GMT+08:00))
>>
>>
>>    - To：卢诗炜<shiwei.lu at 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.lu at 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.lu at 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.angermann at gmail.com>
>>>    - Date：2023-06-07 19:45:32
>>>    - To：卢诗炜<shiwei.lu at 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.lu at 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 at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20230614/0f0fb220/attachment.html>