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.pi...@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.ch...@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.ch...@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-le...@python.org > https://mail.python.org/mailman3/lists/pypy-dev.python.org/ > Member address: tzuhsiang.ch...@gmail.com >
_______________________________________________ pypy-dev mailing list -- pypy-dev@python.org To unsubscribe send an email to pypy-dev-le...@python.org https://mail.python.org/mailman3/lists/pypy-dev.python.org/ Member address: arch...@mail-archive.com
