Contribution: adding support for older PowerPCs

[Jake Hamby]

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:2...@2.33.0.chromium.6 (line 27): no such package: infra/3pp/tools/git/linux-s390x
  failed to resolve infra/3pp/tools/cpython/linux-s390x@version:2...@2.7.18.chromium.39 (line 21): no such package: infra/3pp/tools/cpython/linux-s390x
  failed to resolve infra/3pp/tools/cpython3/linux-s390x@version:2...@3.8.10.chromium.23 (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

[Jakob Kummerow]

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

--

 

[Milad Farazmand]

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.

--
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 v8-ppc-ports...@googlegroups.com.
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
mfar...@redhat.com

[Milad Farazmand]

Sorry for the duplicate email, I noticed Jake's email was missing from the list.

[Jake Hamby]

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

[Milad Farazmand]

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.