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
