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: arch...@mail-archive.com
