Hi, I have good news: the RISC-V backend can pass as many unit tests as the AArch64 backend. I got vmprof and codemap working this weekend. I also completed a full translation and got a workable pypy executable.
I have two questions now: 1. Are there other test suites that I can check for the correctness? 2. How do we measure the performance? Do we have a command line that can run all benchmarks? Thank you in advance. Regards, Logan p.s. All changes are at: https://github.com/loganchien/pypy/tree/rv64 On Mon, Jan 15, 2024 at 8:54 PM Logan Chien <tzuhsiang.ch...@gmail.com> wrote: > Hi Maciej, > > Thank you for your information. Let me conduct more surveys. Thanks. > > Regards, > Logan > > On Thu, Jan 11, 2024 at 2:44 AM Maciej Fijalkowski <fij...@gmail.com> > wrote: > >> Hi Logan >> >> As far as I remember (and neither Armin nor I did any major pypy >> development recently), the vectorization was never really something we >> got to work to the point where it was worth it. In theory, having >> vectorized operations like numpy arrays to compile to vectorized CPU >> instructions would be glorious, but in practice it never worked well >> enough for us to enable it by default. >> >> Best, >> Maciej >> >> On Wed, 10 Jan 2024 at 08:39, Logan Chien <tzuhsiang.ch...@gmail.com> >> wrote: >> > >> > Hi Armin, >> > >> > > About the V extension, I'm not sure it would be helpful; do you plan >> > > to use it in the same way as our x86-64 vector extension support? As >> > > far as I know this has been experimental all along and isn't normally >> > > enabled in a standard PyPy. (I may be wrong about that.) >> > >> > Well, if the vector extension is not enabled by default even for x86-64 >> backend, then I will have to conduct more survey, planning, and designing. >> I haven't read the vectorization code yet. >> > >> > Anyway, I will finish the basic JIT first. >> > >> > Regards, >> > Logan >> > >> > On Tue, Jan 9, 2024 at 2:22 AM Armin Rigo <armin.r...@gmail.com> wrote: >> >> >> >> Hi Logan, >> >> >> >> On Tue, 9 Jan 2024 at 04:01, Logan Chien <tzuhsiang.ch...@gmail.com> >> wrote: >> >> > 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). >> >> >> >> Cool! Here are a few thoughts I had when I looked at some RISC-V >> >> early documents long ago (warning, it may be outdated): >> >> >> >> Yes, not using the "compress" extension is probably a good approach. >> >> That looks like something a compiler might do, but it's quite a bit of >> >> work both implementation-wise, and it's unclear if it would help >> anyway here. >> >> >> >> About the V extension, I'm not sure it would be helpful; do you plan >> >> to use it in the same way as our x86-64 vector extension support? As >> >> far as I know this has been experimental all along and isn't normally >> >> enabled in a standard PyPy. (I may be wrong about that.) >> >> >> >> Singlefloats: we don't do any arithmetic on singlefloats with the JIT, >> >> but it has got a few instructions to pack/unpack double floats into >> >> single floats or to call a C-compiled function with singlefloat >> >> arguments. That's not optional, though I admit I don't know how a C >> >> compiler compiles these operations if floats are not supported by the >> >> hardware. But as usual, you can just write a tiny C program and see. >> >> >> >> I agree that RV32 can be a more remote goal for now. It should >> >> simplify a lot of stuff if you can just assume a 64-bit environment. >> >> Plus all the other points you mention: the hardware may not support >> >> doubles, and may not be supported by Debian... >> >> >> >> >> >> A bientôt, >> >> >> >> Armin Rigo >> > >> > _______________________________________________ >> > 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: fij...@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
