Hi Jake, Thanks for reaching out. That sounds like quite some effort that you've put into this project!
V8's PPC port is maintained by a dedicated team (CC'ed), so they would have to decide whether they want to accept the additional code complexity for supporting additional hardware. Since V8 is under constant development, supporting more CPUs has not just the one-off cost of making things work, but also causes an ongoing maintenance (and testing) burden. Having no experience with the various PPC/POWER architectures myself, I can't estimate how much this burden might be in this case, so this is just a high-level comment. Uploading your work for codereview is certainly a good next step. It may be beneficial to upload several smaller patches, if you have independent features that can be discussed/approved individually. Regarding the prebuilt binaries: you can file a bug at crbug.com, using the "Infra" component, and ask about changing the build flags. When in doubt, on uncommon platforms building required binaries yourself tends to be your best bet (related example: there are no prebuilt toolchains for Linux-arm64, but using distro-provided ninja/gn/clang packages or compiling from source works well). Cheers, Jakob On Mon, Feb 21, 2022 at 6:35 AM Jake Hamby <[email protected]> wrote: > As a hobby project, I've been working on a set of fixes for Void Linux > PPC's packages to run on my vintage PowerMac G5 Quad. One of the packages > that hasn't worked until now is Node.js, because V8 is generating > instructions that didn't exist in Power ISA v2.01. > > V8 already works correctly for IBM POWER back to POWER7, and the patch > I've been working on adds support for POWER6, POWER5/5+ and PA6T, and > POWER4/G5/Cell and older (I haven't tested 32-bit yet), and NXP > e500/e5500/e6500. I've also improved the i-cache syncing code for the older > CPUs that don't have i-cache snooping and have to loop through the data > cache lines and instruction cache lines to invalidate them. Instead of > calling "sync" and "isync" in the loop, the more optimal approach is to > loop with "dcbf", then "sync", then loop with "icbi", then "isync". > > I don't have the hardware to test on, but NXP's e5500/e6500 cores are > still in production, and the T2080, which is being used for an > enthusiast-funded PowerPC notebook project, will be supported through at > least June 2027, so it's not (yet) an obsolete part. Interestingly, the > e5500/e6500 support some of the useful instructions from Power ISA v2.06, > like popcnt and stdbrx, but not others, even old ones like the FP rounding > to integer opcodes added in v2.02 that require POWER5/PA6T or newer. For > purposes of V8, I've broken out the shared opcodes into a new > PPC_7_PLUS_NXP feature flag, as well as one for the "isel" instruction, > which is supported back to the 32-bit NXP CPUs, and has its own feature bit > in Linux's AT_HWCAP2. > > I hope to have something ready for code review by midweek, so I wanted to > introduce myself to the list and try to make sure that someone interested > in Power ISA will see it. The additional code I've added should be > completely transparent to newer CPUs, except that I have optimized the > 64-bit byte reversal to use one fewer scratch register, so there's a > minuscule optimization there. Also, for POWER7 (and earlier), for moving > values between GPRs and FPRs, I've saved two calls to lower and raise the > stack pointer by changing the generated instructions to use a negative > offset from sp instead (POWER8 and above have direct move instructions; > earlier ones need to push and pop to memory). > > Is there anything that I should keep in mind while I'm finishing up this > submission? I'll be sure to sign the contributor agreement and make sure it > passes the test cases. That reminds me: the Go build tools for V8, like > "gclient", don't work on s390x (IBM z15), which I was hoping to use for > big-endian testing, because Google isn't supplying some binary packages: > > Errors: > failed to resolve infra/3pp/tools/git/linux-s390x@version > :[email protected] (line 27): no such package: > infra/3pp/tools/git/linux-s390x > failed to resolve infra/3pp/tools/cpython/linux-s390x@version > :[email protected] (line 21): no such package: > infra/3pp/tools/cpython/linux-s390x > failed to resolve infra/3pp/tools/cpython3/linux-s390x@version > :[email protected] (line 24): no such package: > infra/3pp/tools/cpython3/linux-s390x > > And I can't run gclient on my G5 at home because the Go binaries are > compiled for POWER8 and above. Would it be possible to compile at least > those necessary build tools for generic 64-bit PPC, if you're going to have > a big-endian Linux PPC version? It's not as if they're especially > CPU-intensive. I understand why Go itself defaults to POWER8 now, but I'd > really appreciate it if someone could override the default CPU for that > case, since there are pre-POWER8 big-endian ppc64 systems. It's a small > change, but it would be very helpful for those of us with vintage PowerMacs. > > Thanks in advance, > Jake Hamby > > -- > -- -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/CAKSzg3Txzy9JFUycikkfnvj1V%3DnEmMRVobZa%3DT3Gbj9oSv_dWQ%40mail.gmail.com.
