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] -- -- 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/CABfdNnRWdmPT06yYTVWT1h%3DRsnfbhYp%3Dcx1%2BV9Q2i0PKsVrJ_A%40mail.gmail.com.
