There isn't a way to detect POWER5+ atm. To enable detection a `cpu.part()` check must be added under `CpuFeatures::ProbeImpl`, however we can't test its functionality as we don't support it anymore. We will likely remove checks for p6 and p7 as well. The default case atm should fall under a processor <p6, essentially none of the features of p6+ should get enabled. Under the cleanup work item we do have a task to add an `UNREACHABLE();` call for unsupported processors.
On Tue, Feb 22, 2022 at 4:15 PM Jake Hamby <[email protected]> wrote: > Thanks for the useful info. I know supporting decade-old CPUs is the > lowest possible priority for you, but as a hobby project, learning > about the JIT and the instructions added from Power ISA v2.01 to today > was very educational. A few small questions about the code: > > - The ARM and PPC CPU model detection in src/base/cpu.cc is using > getauxval() on Linux on glibc 2.16 or newer, but opening > "/proc/self/auxv" by hand otherwise, and then stepping through the ELF > auxv list entries. Is there a good reason why a version of glibc from > Mar. 2012 is still supported in the current codebase? The code is > cleaner if I can just assume PPC on Linux is at least glibc 2.18 > (released Aug. 2013), for AT_HWCAP2 (or musl libc), but I can keep the > "/proc/self/auxv" code if there's a good reason for it. > > - Is there a way on AIX to detect POWER5+ vs. POWER5? It's only > useful to know for the "isel" instruction. I also notice there's no > default POWER value if it doesn't recognize the value of > "_system_configuration.implementation", so it doesn't get properly > handled. Should that case statement default to POWER_10 (assuming it's > something newer), POWER_5 (for safety), or something in between? > > BTW, please ignore my claim that I figured out a better code path to > byte swap reverse a 64-bit integer. I tested my version and it failed > some test cases, and I'm guessing it's because the code I copied from > GCC only works when the input and output registers are different. In > the case where they're the same, you do need three scratch registers > instead of two to hold all the temp values. The CPU simulator really > saves a lot of time. > > Regards, > Jake Hamby > > On Tue, Feb 22, 2022 at 12:45 PM Milad Farazmand <[email protected]> > wrote: > > > > 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 > . > >> > >> > >> > >> -- > >> > >> Milad Farazmand > >> > >> Red Hat Runtimes > >> > >> [email protected] > > > > > > > > -- > > > > 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/CAMDiSz9UAnfx%3DCSwzAjeEyEQeizPchDX2ydT1xnq82COY7fthg%40mail.gmail.com.
