The availability of hardware is not what matters. The use of the hardware is what matters. I am unaware of anyone using Go on POWER5 except you, Minux, and I suspect even you don't use it very often. The machine is too slow!

In contrast, we heard from multiple companies using ARMv5.

Minux, are you asking compatibility with power5 or ppc970 because they aren't the same. We agreed to compatibility with power5 at one time and it was documented that way and I believe some instructions were added last year that were compatible with power5 but not ppc970. This is part of my point. The power5 compatibility is not even being verified and I'm not sure if that is even what you want.

You used the word hard, but my point is that it requires extra work and requires extra "clutter" in the code through #ifdefs and extra files and more complicated if statements. Here are some examples. That is why I am asking this question now. Let's decide this so we know how to proceed in Go 1.9. If we knew of other users I'd have no concern with continuing to maintain it but I don't know of anyone else.

Example 1: the And8 and Or8 atomic functions. On ppc64le they use the LBAR and STBCC because that is really what the code should be doing: get the reservation on the byte, not the word. But because in power5 those instructions don't exist we have to do some extra loads and shifts and get the reservations on the entire word (4 bytes) for ppc64. Now I want these to be intrinsics. I really only care if ppc64le performs better, so I'd like to say don't make these intrinsics, but the way intrinsics are determined in the gc/ssa.go code is based on the family, which is the same for ppc64 and ppc64le so is not specific enough in this case. Yes I can add an extra check to see if this is only ppc64le but in the past I've gotten comments from others in the community about making the code too cluttered when I try to do stuff like this. If we allow these to be intrinsics for both then I have to implement separate code sequences for ppc64le and ppc64. Not hard, just extra work to do and test.

Example 2: Many, many crypto, math, and math/big functions can be improved by using VMX and VSX instructions not available in power5. Most of these can be done through their own ppc64le.s file but there will be some that could be improved by having the compiler generate the instructions directly.

Example 3: I have a better implementation of IndexByte that is not compatible with power5. I could use basically the same implementation for ppc64le and ppc64 (this one does require 2 #ifdefs in the function for endianness differences) if they could use the same instruction set. Otherwise they have to be totally different. There are other byte functions that can be improved that will have the same situation.

Example 4: There is also a separate code sequence in ppc64/ssa.go for the isel instruction because that one is not in power5.

@minux, as far as commercial vs open source, I think you have it backwards. The Go open source project does not aim to make every port freely or cheaply usable by all users, including individuals. Instead, the Go open source project aims to be useful on whatever hardware is commonly used by its users, whether those users are individuals or companies. It is true that individuals have easy access to x86 and arm and arm64, but not to some of the other ports (ppc64le, s390x). That doesn't make those ports less useful or somehow "the wrong direction for an open source project". It's OK to support expensive hardware that individuals would probably not choose to or be able to buy.

Here is a thought experiment. Suppose that we had ppc64 and ppc64le meaning POWER8+ already and that those ports were not reusable for the PowerMac G5, and then suppose someone came to us and said they wanted to add a new port to the PowerMac G5. We'd naturally ask how many users would benefit from such a port. If the answer was "maybe one person", we'd almost certainly say no, it's not worth the maintenance burden.

From my point of view, that's the situation we are in. The team at IBM that is maintaining the ppc64 and ppc64le ports is held back by support for this old system that maybe one person uses (and that might actually already be broken and unreported, per @laboger's comment above). I've been asking for a few days, and there is basically no evidence that this is an important system to even a significant minority of our potential user base. You're the only one who wants this.

You do have a point about architecture variation, but that point doesn't counter the "why are we spending effort to maintain a system that only one person actually uses?" point. We can wait to address architecture variation when we have both an older system that is important to keep working and a newer system that is important to optimize for. Right now we only have the latter.

Finally, if "hardware availability matters a lot", then that's an argument against keeping the PowerMac G5 working too, since it's not generally available in a warrantied, supported form. It was discontinued over ten years ago and the only way to get one is to buy a 10+ year-old system on eBay, install a different OS, and hope it works.

For all these reasons, I am inclined to accept the proposal to make POWER8 the new requirement for the ppc64 port.

I just noticed that according to this page, the ppc64 builder is a power7. I'm not sure if this is current, because it was my understanding that both ppc64 and ppc64le builders were power8.

https://github.com/golang/go/wiki/DashboardBuilders

Brad verified that the builders are both power8 and the wiki has been updated. It does say on this wiki that the ppc64 builder on Minux' ppc970 machine no longer works.

Thanks for investigating. Proposal accepted, for the reasons I gave in my comment 7 days ago.

Should have left open - there's probably documentation or other work to be done.

CL https://golang.org/cl/38404 mentions this issue.

CL https://golang.org/cl/38406 mentions this issue.

CL https://golang.org/cl/39010 mentions this issue.

This seems to have happened.

There might be more to do, but it's not a blocker to use POWER8 features in all POWER assembly before marking this closed. It's already noted for the release notes. So, closing.

In case some other POWER5 user is disgruntled as I am, getting golang-1.9 to build on POWER5 again is a matter of reverting 189053a, c644a76, 4a11404. and 475f02c (in that order). Just successfully built golang-1.9 on Debian unstable ppc64 using these changes.

Full patch available in: http://paste.debian.net/984459/

I appreciate your work @glaubitz; unfortunately, this really does only work for POWER5. I'm trying to package Go for our distribution, Adélie Linux, which is based on the musl libc. We only have a few dozen users right now, but we already have a few vocal users of Go that would love to use it on their Adélie machines. Our PPC64 packages are built with -mcpu=970 and I personally use a Power Mac G5 as my primary workstation, as do a few of our users. (Another is running a business off of an IBM POWER5 blade.) With the patch provided in the last comment, I am still seeing SIGILL in Atomic.Or8 when trying to bootstrap a crossed build from x86_64.

We – users of the 970 and other older-than-P8 PPC64 machines – definitely do still exist, and it is readily apparent to me that there is a non-zero amount of people who use the 970 and want to use Go language on it. Is this at all something that can be put back in Go? If not, perhaps @glaubitz and I could do a deeper dive on finding a way to make it build and run on the 970 in addition to the POWER5 ISA, and I could maintain the patches locally with our Go supporter/volunteer.

Thank you.

Our PPC64 packages are built with -mcpu=970 and I personally use a Power Mac G5 as my primary workstation, as do a few of our users.

That's actually the baseline we use in Debian as well, we have recently even disabled AltiVec by default because many users run Debian ppc64 on Freescale E5500 machines.

With the patch provided in the last comment, I am still seeing SIGILL in Atomic.Or8 when trying to bootstrap a crossed build from x86_64.

Can you run the binary in gdb and run "x/i" with the address of the SIGILL instruction? Then we can figure out what instruction caused the problem and I can look which patch I need to revert.

We – users of the 970 and other older-than-P8 PPC64 machines – definitely do still exist, and it is readily apparent to me that there is a non-zero amount of people who use the 970 and want to use Go language on it. Is this at all something that can be put back in Go?

I suggest you make a post to golang-dev and I'll join the discussion.

I also still don't understand why the baseline for ppc64be was raised to POWER8 because there is no operating system according to my best knowledge which runs in POWER8 big-endian mode. Virtually everyone using POWER8 hardware is running a little-endian operating system.

I have the impression that IBM folk want to forcefully deprecate older POWER machines to drive their POWER8/9 sales. I have also seen similar attempts from IBM folk in other projects where they tried to dismiss patches for supporting older POWER versions by claiming they were deprecated as if IBM is the only manufacturer of POWER hardware, ignoring companies like Freescale.

Luckily, other projects like Rust-Lang and OpenJDK have a better attitude than Golang in this regard and there IBM folk hasn't yet managed to force older POWER hardware into deprecation.

Thanks @laboger, I've reverted 3311275. Still seeing SIGILL in atomic.Or8:

Program received signal SIGILL, Illegal instruction.
0x0000000000048b1c in runtime.check () at /usr/src/aports/community/go/src/go/src/runtime/runtime1.go:257
257             atomic.Or8(&m[1], 0xf0)
(gdb) x/8i ($pc - 8)
   0x48b14 <runtime.check+516>: li      r5,-16
   0x48b18 <runtime.check+520>: hwsync
=> 0x48b1c <runtime.check+524>: lbarx   r31,0,r4
   0x48b20 <runtime.check+528>: or      r31,r31,r5
   0x48b24 <runtime.check+532>: stbcx.  r31,0,r4
   0x48b28 <runtime.check+536>: bne     0x48b1c <runtime.check+524>
   0x48b2c <runtime.check+540>: isync
   0x48b30 <runtime.check+544>: lbz     r5,72(r1)

LBARX is POWER8. This should also crash e5500 as it wasn't added until e6500. Then again, I don't see LI in the old or new version of atomic.Or8. Anyway, this should have been fixed with the reversion of 189053a, so I'm not sure why it's still there. Perhaps I need to dig deeper and ensure that the Go toolchain that generates this toolchain has the patch applied properly.

@awilfox Thanks for the heads-up. I will revert 3311275 and 189053a in my tree.

I also wasn't implying that it works on e5500. Debian's ppc64 buildds are actually POWER7 and POWER8 which why the two missing reverts slipped through and why the builds failed only sporadically.

@glaubitz your go1.9 fork should work if you did not pick up my changes from the time when we deprecated code older than POWER8. Otherwise, there are plenty of new implementations in runtime/asm_ppc64x.s and math/big/arith_ppc64x.s that use newer instructions and will crash on POWER5.

Is this still a problem?

As of 1.10 and #24358, yes, it is.

This is still blocking Go being packaged in Adélie, and this is still preventing others on RHEL7, Debian, etc from using the Go packages that are available for their ppc64 systems (if the CPU is < POWER8 or < e6500).

@awilfox I have switched the default Go compiler for "ppc64" on Debian to gccgo now to work around this issue. Most of the packages build fine, although there are some that cause problems when being built with gccgo instead of golang. I am planning to report those packages to gccgo upstream as Ian Lance Taylor asked me to. But I am currently busy with other projects.

@Xe As for golang, I have just rebased my POWER5 branch and resolved all the merge conflicts. Let's see if it still builds. Overall, there is not much effort necessary to get golang to build fine on POWER5.

Another +1 for a problem.

I don't see much purpose in having ppc64 be POWER8 only; the pool of possible users is small as:

• the user not using Linux; but using AIX or i instead, and ports don't exist for those (yet?)

• the user is on big endian and using Linux, but using pre-POWER8 CPUs

• the user is on POWER8 and using Linux, but ppc64le is a no brainer due to support heading in that direction due to various factors

It seems that making big endian ppc64 require POWER8 is a de facto deprecation without actually doing a deprecation, as the platform support matrices are in a way that makes the user base for big endian POWER8 Linux extremely small. Your best routes are to consider allowing ppc64be tolerate pre-POWER8 or just send the port to a farm upstate.

Ping. This is still blocking us. Will there be any resolution? gccgo doesn't work properly on musl due to ucontext issues, so that didn't end up being a solution.

We're still blocking on this, a full year later, and it's actually prevented us from doing things like using GitLab CI (which requires Go) or writing some internal projects using Go…

@awilfox This issue is closed, so pinging here won't help. I'm not aware of any plans to change this decision.

If you have problems using gccgo, please report them.

I was investigating whether golang can be used on embedded platforms like e5500 and was supposed to leave this without comment but I decided to express my opinion so community voice has been heard.

I don't understand why such decision was made. I had plans to make an application for embedded platform and this is a blocker for me and I think it is for everybody who is investigating whether golang can be used.

In my opinion this is classical egg and chicken problem: we won't support because there aren't too many users and there aren't too many users because a given platform is not well supported.

I can't afford to support a custom branch just to be able to build it has to be officially supported.

@DariuszOstolski, you didn't say why gccgo doesn't work for you.

@bradfitz gccgo doesn't build all packages that golang builds. I know it's supposed to be compatible, but it isn't. I can provide a list of Debian packages which don't build.

See, for example, etcd: https://buildd.debian.org/status/fetch.php?pkg=etcd&arch=ppc64&ver=3.2.18%2Bdfsg-1&stamp=1539989343&raw=0

Fails with:

# github.com/coreos/etcd/pkg/cpuutil
src/github.com/coreos/etcd/pkg/cpuutil/endian.go:31:13: error: array bound is not constant
  if v := (*[intWidth]byte)(unsafe.Pointer(&i)); v[0] == 0 {
             ^
src/github.com/coreos/etcd/pkg/cpuutil/endian.go:31:51: error: array index out of bounds
  if v := (*[intWidth]byte)(unsafe.Pointer(&i)); v[0] == 0 {
                                                   ^

Builds fine with golang: https://buildd.debian.org/status/fetch.php?pkg=etcd&arch=ppc64el&ver=3.2.18%2Bdfsg-1&stamp=1523405069&raw=0

@glaubitz, anytime you find a case where any two Go compilers have different behavior, please file a bug. We consider that a big problem and try to fix those bugs quickly and will add new tests to make sure it doesn't recur in the future.

@ianlancetaylor et al will fix gccgo bugs quickly. That's a more fruitful avenue for getting old ppc64 support, because it's not coming back to the golang.org compiler.

I filed #28601 for the gccgo issue.

old ppc64 support

You realise POWER7 was the current generation from 2010-2014, right? You have deprecated something that is newer than Intel Sandy Bridge, and was the current POWER CPU when Haswell came out.

The golang Go compiler also supports ARM going back to ARMv6 because of niche uses like smartphones and the RasPi 1. But you won't support a CPU more than 4 years old that has a larger (and obviously more vocal) userbase – ranging from hobbyists with Apple G5, newer computers based on the AmigaOne designs, people with 4 year old IBM servers, etc?

I would have let this thread die, but calling anything pre-POWER8 "old" is downright insulting to the community.

I'll also note that we can't get any support for gccgo bugs because none of the versions newer than 6 branch work for our distribution. GCC 7 has horrifying regressions on basically "anything that isn't x86"; GCC 8 uses 3-5× the RAM over GCC 6 for the same workloads, which means less packages being built at one time because our builders have to have less jobs running at once. Go ahead, tell me to go complain to the GCC maintainers. Even when 6 was a supported branch they didn't care about us, and they won't even fix bugs present in 7 and 8. So when we have issues with gccgo such as "segfaulting on ppc64" (and only ppc64), we are shown the door.

At this point, we're probably going to have to drop Go from our repositories.

In embedded world those devices will have to be supported for at least 20 years and e5500 is a very powerful processor even now.

Also - another reason to support POWER5-levels is a (potential) port to AIX and IBM i. Doing this would cover the other operating systems in the POWER ecosystem. IBM i is binary compatible with AIX, however, it SIGILLs on anything above POWER5.

The argument wrt. cost of hardware also remains valid - even POWER7 machines still sell for thousands of USD in the second hand market, and POWER8 machines are unobtainium. I have several customers who are running P5 and P6 in prod and will be for years to come because of the price point of P8 and P9 and that there is no entry level market for their needs.

We are using e6500/e5500 cores now(and in the next ten years, probably). I believe there are many company other than ZTE are using these cores as well, and they also need golang (and docker? I suppose). So, I think it is definitely worthwhile to support these 'old ppc64'.

We have added basic support for e6500 on golang1.10.3 . We have build docker and it looks fine. Our final goal is to make ppc64 (on e6500/5500) support most features of ppc64le. We are willing to contribute our work to the community. The first patch (about cgo support) have been merged(1135071).

To add e6500 support , we do three major changes.
The first is adding a new environment variable GOPPC( which should be "" or "e6500").
The second is adding some objabi controlls in cmd/compile/internal/ssa/gen/PPC64.rules (just like what ARM do).
The third is adding controls for codes in runtime/math packages.
These changes do not break POWER8 support, and are very small (several hundred lines in total).
If the community decides to support e6500/e5500, we are happy to contribute these changes.
@rsc @minux @friedkiwi @awilfox @glaubitz @DariuszOstolski

That would be absolutely perfect! Having the ability to select different PPC ISA levels would solve all the issues, still provide the enhancements that upstream seems to desire for POWER8, and allow it to be used on other cores. It should be easy to support e5500 and 970 and P7 with GOPPC in addition to e6500. Thank you for this initial work.

@zte-majiang Oh, that's awesome. Thanks a lot for doing this. I agree to what @awilfox says, e5500, 970 and P7 should be added as well!

Only nitpick I can see in that patch is that ABI is independent from endianness and POWER6 is a thing too.

happy to see that someone like our work :)
To make things more clear:
1 As we are going to support e6500 internally for sure, (if the community thinks that's ok)we are willing to become the maintain team of PPC64 port.
2 In my opinion, golang really need the multiple ISA support as go have being more widely used. The most important work is to create a hierarchy framework for runtime libraries(runtime/math packages) just as what glibc do in the sysdep subdirectory, see examples as below:
./powerpc/powerpc64/multiarch/wcsrchr-power6.c
./powerpc/powerpc64/multiarch/wcsrchr-power7.c
./powerpc/powerpc64/power4/memcmp.S
./powerpc/powerpc64/power5+/fpu/s_ceil.S
3 I agree with @laboger that to support a older ISA in current golang codes need extra work (after we build the hierarchy framework mentioned above, adding ISA support should be very easy and low cost), because codes for different ISA are often mixed together in one file now. So, at the very beginning, only the most wanted ISA should be added. For ppc64, we could just go back to POWER5 at the first step. Anyway, POWER6/POWER7 machines could run POWER5 binaries.
@rsc @laboger @glaubitz @NattyNarwhal @awilfox

@NattyNarwhal : "but using AIX or i instead, and ports don't exist for those (yet?)" :

• golang v1.12 will be available for AIX 7.2 / Power8&9 soon, without cgo, not 100% perfect.
• golang v1.13 on AIX will provide cgo, and its quality/reliability should be very high.
• IBMi guys have started to study/start the port of golang, based on our work.

Also, the AIX port has been noted as requiring "whatever the Linux/Power port does", so when POWER5 support lands back in golang.org where it belongs, the AIX port should be able to support the many production servers with POWER7 hardware.