Sorry for the duplicate email, I noticed Jake's email was missing from the list.
Hi Jake, > Thank you for your time investigating V8 issues on PPC. > > We do not maintain or test any changes on PPC < Power8. You are > definitely welcome to upload your changes, however, we will only be able to > review and test them for running on >= Power8. We are in the process of > adding optimizations for new processors (Power9 and 10) as well as > removing any older and unsupported codebase. You will need to maintain the > main branch for your changes on a daily/weekly basis otherwise it could > break very quickly. > > The only big-endian PPC we support is AIX and IBMi, we do > not support Linux on BE Power. > The gclient errors on S390 can be ignored for now, we don't really use any > of the packages from gclient. > > Hope this helps. > > On Mon, Feb 21, 2022 at 7:40 AM Jakob Kummerow <[email protected]> > wrote: > >> 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 >>> >>> -- >>> >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "v8-ppc-ports" 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-ppc-ports/CAKSzg3Txzy9JFUycikkfnvj1V%3DnEmMRVobZa%3DT3Gbj9oSv_dWQ%40mail.gmail.com >> <https://groups.google.com/d/msgid/v8-ppc-ports/CAKSzg3Txzy9JFUycikkfnvj1V%3DnEmMRVobZa%3DT3Gbj9oSv_dWQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > > > -- > > *Milad Farazmand* > > Red Hat Runtimes > > [email protected] > > -- *Milad Farazmand* Red Hat Runtimes [email protected] -- -- 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/CAMDiSz_cmUKXitQGYH41qTOTc011aESYcjyBQ6MnjTVdPrujPg%40mail.gmail.com.
