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 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
> 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
> 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
>
