Hi Logan, On Tue, 9 Jan 2024 at 04:01, Logan Chien <tzuhsiang.chien@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