Hi,

> I have not taken any looks at all, but can you tell me what kind of setup does one need for testing it? Are you using real hardware or emulation?

Currently, I use "qemu-user-static + schroot + Debian riscv64 root filesystem" on an x86-64 host.

I have a HiFive Unmatched board as well. But I haven't figured out how to install Debian riscv64 for this board yet. Also, given its price tag, I think I will only run benchmarks on it instead of doing toolchain translation on it (though it should have enough DRAM).

> is there only one compilation target or would the backend need to know about the different ISA extensions?

Currently, I only target RV64 IMAD:

I - Base instruction set

M - Integer multiplication

A - Atomic (used by call_release_gil)

D - Double precision floating point arithmetic

I don't use the C (compress) extension for now because it may complicate the branch offset calculation and register allocation.

I plan to support the V (vector) extension after I finish the basic JIT support. But there are some unknowns. I am not sure whether (a) I want to detect the availability of the V extension dynamically (thus sharing the same pypy executable) or (b) build different executables for different combinations of extensions. Also, I don't have a development board that supports the V extension. I am searching for one.

Another remote goal is to support RV32IMAF (singlefloats) or RV32IMAD. In RISC-V, 32-bit and 64-bit ISAs are quite similar. The only difference is on LW/SW (32-bit) vs. LD/SD (64-bit) and some special instructions for 64-bit (e.g. ADDW). I isolated many of them into load_int/store_int helper functions so that it will be easy to swap implementations. However, I am not sure if we have to change the object alignment in `malloc_nursery*` (to ensure we align to multiples of `double`). Also, I am not sure whether it is common for RV32 cores to include the D extension. But, anyway, RV32 will be a lower priority for me because I will have to figure out how to build a RV32 root filesystem first (p.s. Debian doesn't (officially) support RV32 as of writing).

> As for patch review and merging: we have a history of long-lived branches in PyPy. Two examples: ..., so it would have been better to hold off until it was more completely finished. Something tho think about.

Sure. This approach works for me too.

Regards,

Logan

On Mon, Jan 8, 2024 at 8:21 AM Matti Picus <matti.picus@gmail.com> wrote:

On 8/1/24 10:03, Maciej Fijalkowski wrote:
> Hi Logan
>
> Very cool you are interested in that! It's often useful to hang out on
> IRC as you can ask questions directly. I have not taken any looks at
> all, but can you tell me what kind of setup does one need for testing
> it? Are you using real hardware or emulation?
>
> The approach of starting with tests and getting translation done later
> is very much what we have done in the past.
>
> Best,
> Maciej
>
> On Mon, 8 Jan 2024 at 09:42, Logan Chien <tzuhsiang.chien@gmail.com> wrote:
>> Hi,
>>
>> I forgot to include the link in my previous email.
>>
>> If you want to have a look on my prototype, you can find it here:
>> https://github.com/loganchien/pypy/tree/rv64
>>
>> Thanks.
>>
>> Regards,
>> Logan
>>
>>
>>
>> On Sun, Jan 7, 2024 at 5:18 PM Logan Chien <tzuhsiang.chien@gmail.com> wrote:
>>> Hi all,
>>>
>>> I would like to contribute a RISC-V 64 JIT backend for RPython. I have made some progress at the end of 2023.
>>>
>>> ## Status
>>>
>>> My prototype can pass the test cases below:
>>>
>>> * test_runner.py
>>> * test_basic.py and almost all test_ajit.py related tests (except test_rvmprof.py)
>>> * test_zrpy_gc_boehm.py
>>>
>>> I am still working on test_zrpy_gc.py though (p.s. I can pass this if I disable malloc inlining).
>>>
>>> I haven't done a full translation yet.
>>>
>>> ## Logistic
>>>
>>> I wonder how you would like to review the patches? I have roughly 73 pending commits. Each commit has a specific reason for change and corresponding test cases (if applicable).
>>>
>>> Is it better to just send one GitHub Pull Request containing all of them?
>>>
>>> Or, do you prefer one commit per Pull Request?
>>>
>>> Thank you.
>>>
>>> Regards,
>>> Logan

Exciting, thanks!

I find IRC too temporary: it is hard to search through. This can be both
an advantage and a disadvantage. Maybe since we have moved development
efforts to github we could try out the github discussions platform. I
opened it up at https://github.com/orgs/pypy/discussions. Of course you
are welcome to use IRC if you are comfortable with it.

In addition to Maciej's questions: is there only one compilation target
or would the backend need to know about the different ISA extensions?

As for patch review and merging: we have a history of long-lived
branches in PyPy. Two examples: the windows 64-bit branch was only
merged once it was quite ready, and led to only small breakage of the
main branches. I recently merged the hpy0.9 branch too early, and the
failing tests masked some other py3.9 failures until I got it under
control, so it would have been better to hold off until it was more
completely finished. Something tho think about.

Matti

_______________________________________________
pypy-dev mailing list -- pypy-dev@python.org
To unsubscribe send an email to pypy-dev-leave@python.org
https://mail.python.org/mailman3/lists/pypy-dev.python.org/
Member address: tzuhsiang.chien@gmail.com