Re: Contribute a RISC-V 64 JIT backend
Logan Chien <[email protected]> Tue, 9 Jan 2024 22:39:17 -0800
| Newsgroups | gmane.comp.python.pypy |
|---|---|
| Message-ID | <CALQyFuBJC65W4ZWGfVgAfYvwC+S+5pdjKqMbnAm58MB+uaTxFg@mail.gmail.com> |
--===============8587188206537999719== Content-Type: multipart/alternative; boundary="0000000000004fe0e4060e91b139" --0000000000004fe0e4060e91b139 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=AFAM Armin Rigo <[email protected]> wr= ote: > Hi Logan, > > On Tue, 9 Jan 2024 at 04:01, Logan Chien <[email protected]> > 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 complicat= e > 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 help= er > 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 i= t > 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=C3=B4t, > > Armin Rigo > --0000000000004fe0e4060e91b139 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>Hi Armin,</div><div><br></div><div>> About the V e= xtension, I'm not sure it would be helpful; do you plan</div>> to us= e it in the same way as our x86-64 vector extension support?=C2=A0 As<br>&g= t; far as I know this has been experimental all along and isn't normall= y<br><div>> enabled in a standard PyPy.=C2=A0 (I may be wrong about that= .)</div><div><br></div><div>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.=C2=A0 I haven't read the vectorization code ye= t.<br></div><div><br></div><div>Anyway, I will finish the basic JIT first.<= /div><div><br></div><div>Regards,</div><div>Logan<br></div></div><br><div c= lass=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Jan 9, 2= 024 at 2:22=E2=80=AFAM Armin Rigo <<a href=3D"mailto:[email protected]= m">[email protected]</a>> wrote:<br></div><blockquote class=3D"gmail_= quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,= 204);padding-left:1ex">Hi Logan,<br> <br> On Tue, 9 Jan 2024 at 04:01, Logan Chien <<a href=3D"mailto:tzuhsiang.ch= [email protected]" target=3D"_blank">[email protected]</a>> wrote:<b= r> > Currently, I only target RV64 IMAD:<br> ><br> > I - Base instruction set<br> > M - Integer multiplication<br> > A - Atomic (used by call_release_gil)<br> > D - Double precision floating point arithmetic<br> ><br> > I don't use the C (compress) extension for now because it may comp= licate the branch offset calculation and register allocation.<br> ><br> > I plan to support the V (vector) extension after I finish the basic JI= T support.=C2=A0 But there are some unknowns.=C2=A0 I am not sure whether (= a) I want to detect the availability of the V extension dynamically (thus s= haring the same pypy executable) or (b) build different executables for dif= ferent combinations of extensions.=C2=A0 Also, I don't have a developme= nt board that supports the V extension.=C2=A0 I am searching for one.<br> ><br> > Another remote goal is to support RV32IMAF (singlefloats) or RV32IMAD.= =C2=A0 In RISC-V, 32-bit and 64-bit ISAs are quite similar.=C2=A0 The only = difference is on LW/SW (32-bit) vs. LD/SD (64-bit) and some special instruc= tions for 64-bit (e.g. ADDW).=C2=A0 I isolated many of them into load_int/s= tore_int helper functions so that it will be easy to swap implementations.= =C2=A0 However, I am not sure if we have to change the object alignment in = `malloc_nursery*` (to ensure we align to multiples of `double`).=C2=A0 Also= , I am not sure whether it is common for RV32 cores to include the D extens= ion.=C2=A0 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).<br> <br> Cool!=C2=A0 Here are a few thoughts I had when I looked at some RISC-V<br> early documents long ago (warning, it may be outdated):<br> <br> Yes, not using the "compress" extension is probably a good approa= ch.<br> That looks like something a compiler might do, but it's quite a bit of<= br> work both implementation-wise, and it's unclear if it would help anyway= here.<br> <br> About the V extension, I'm not sure it would be helpful; do you plan<br= > to use it in the same way as our x86-64 vector extension support?=C2=A0 As<= br> far as I know this has been experimental all along and isn't normally<b= r> enabled in a standard PyPy.=C2=A0 (I may be wrong about that.)<br> <br> Singlefloats: we don't do any arithmetic on singlefloats with the JIT,<= br> but it has got a few instructions to pack/unpack double floats into<br> single floats or to call a C-compiled function with singlefloat<br> arguments.=C2=A0 That's not optional, though I admit I don't know h= ow a C<br> compiler compiles these operations if floats are not supported by the<br> hardware.=C2=A0 But as usual, you can just write a tiny C program and see.<= br> <br> I agree that RV32 can be a more remote goal for now.=C2=A0 It should<br> simplify a lot of stuff if you can just assume a 64-bit environment.<br> Plus all the other points you mention: the hardware may not support<br> doubles, and may not be supported by Debian...<br> <br> <br> A bient=C3=B4t,<br> <br> Armin Rigo<br> </blockquote></div> --0000000000004fe0e4060e91b139-- --===============8587188206537999719== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pypy-dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/pypy-dev.python.org/ Member address: [email protected] --===============8587188206537999719==--