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