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:
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
Is it better to just send one GitHub Pull Request containing all of
On 8/1/24 10:03, Maciej Fijalkowski wrote: pending commits. Each commit has a specific reason for change and corresponding test cases (if applicable). 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