Help Wanted: Gc compiler support for e6500 CPU (ppc64)

482 views
Skip to first unread message

mboillot

unread,
Aug 15, 2018, 5:48:26 PM8/15/18
to golang-dev

Hi everyone, we’re looking to run Go on NXP e5500/e6500 CPU’s.  We’ve had mixed success using gccgo in that we couldn’t get Cgo working.  We’d prefer to have Go natively supported, but haven’t made much progress. A July 2018 post on NXP’s site indicated there is no internal NXP project to provide requested support for QorIQ processors: https://community.nxp.com/thread/480239.  We've also read the links on https://github.com/golang/go/issues/19075 and https://github.com/golang/go/issues/19074. Are there any recommendations for the best way to get this support added into the mainline?  We’re willing and able to supply hardware (e.g., multiple T4240RDB units), sweat equity (with guidance), and money in support of this effort!

David Chase

unread,
Aug 15, 2018, 6:30:31 PM8/15/18
to mboi...@gmail.com, golang-dev
Which version of Power is that?
And you would want it to be Big-Endian, correct?
And it runs a version of Linux, recent I hope?

I'm not sure of the best way, but this information helps figure out the best way.
One thing I know we'll need for mainline support is machines to run tests (builders, trybots).

Another possible option is gollvm (which I am learning aboiut myself right now, for purposes of testing and benchmarks).

On Wed, Aug 15, 2018 at 5:48 PM mboillot <mboi...@gmail.com> wrote:

Hi everyone, we’re looking to run Go on NXP e5500/e6500 CPU’s.  We’ve had mixed success using gccgo in that we couldn’t get Cgo working.  We’d prefer to have Go natively supported, but haven’t made much progress. A July 2018 post on NXP’s site indicated there is no internal NXP project to provide requested support for QorIQ processors: https://community.nxp.com/thread/480239.  We've also read the links on https://github.com/golang/go/issues/19075 and https://github.com/golang/go/issues/19074. Are there any recommendations for the best way to get this support added into the mainline?  We’re willing and able to supply hardware (e.g., multiple T4240RDB units), sweat equity (with guidance), and money in support of this effort!

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

minux

unread,
Aug 15, 2018, 10:01:46 PM8/15/18
to David Chase, mboi...@gmail.com, golang-dev
On Wed, Aug 15, 2018 at 6:30 PM, 'David Chase' via golang-dev <golan...@googlegroups.com> wrote:
Which version of Power is that?
e5500 is Power ISA v2.06, similar to Power 7.

Unfortunately, our ppc64 big endian port dropped support for older BE ISAs (prior to Power 8) in Go 1.9.
(I always think that's a mistake as there are a lot of older BE machines in field and still in active production.)

e6500, on the other hand, is Power ISA v2.07, similar to Power 8. Go should work on that, no?

What was the problem of gccgo on that e5500/e6500?

Ian Lance Taylor

unread,
Aug 16, 2018, 12:55:50 AM8/16/18
to mboillot, golang-dev
On Wed, Aug 15, 2018 at 10:34 AM, mboillot <mboi...@gmail.com> wrote:
>
> We’ve had
> mixed success using gccgo in that we couldn’t get Cgo working.

At least with GCC 8 cgo should work with gccgo just as it does with
the gc toolchain. It is installed and tested. If it doesn't work for
you in cases where it works with gc, please report bugs. Thanks.

Ian

REIX, Tony

unread,
Aug 16, 2018, 4:47:10 AM8/16/18
to mboillot, golang-dev

Hi,


I have no idea about the differences between AIX 7.2/Power 8 and your NXP PowerPC e6500 machines.

Anyway, we have ported & delivered GCC 8.2 (with Go 1.10) on AIX 7.2/7.1 for IBM PowerX machines, with cgo.

And we are finalizing the port of golang v1.11 on AIX 7.2 for Power8/9 machines, without cgo for now.


Regards


Cordialement,

Tony Reix

tony...@atos.net

ATOS / Bull SAS
ATOS Expert
IBM Coop Architect & Technical Leader
1 rue de Provence - 38432 Échirolles - France

De : golan...@googlegroups.com <golan...@googlegroups.com> de la part de mboillot <mboi...@gmail.com>
Envoyé : mercredi 15 août 2018 19:34:57
À : golang-dev
Objet : [golang-dev] Help Wanted: Gc compiler support for e6500 CPU (ppc64)
 

Hi everyone, we’re looking to run Go on NXP e5500/e6500 CPU’s.  We’ve had mixed success using gccgo in that we couldn’t get Cgo working.  We’d prefer to have Go natively supported, but haven’t made much progress. A July 2018 post on NXP’s site indicated there is no internal NXP project to provide requested support for QorIQ processors: https://community.nxp.com/thread/480239.  We've also read the links on https://github.com/golang/go/issues/19075 and https://github.com/golang/go/issues/19074. Are there any recommendations for the best way to get this support added into the mainline?  We’re willing and able to supply hardware (e.g., multiple T4240RDB units), sweat equity (with guidance), and money in support of this effort!

--

lab...@gmail.com

unread,
Aug 16, 2018, 9:49:00 AM8/16/18
to golang-dev


On Wednesday, August 15, 2018 at 4:48:26 PM UTC-5, mboillot wrote:

Hi everyone, we’re looking to run Go on NXP e5500/e6500 CPU’s.  We’ve had mixed success using gccgo in that we couldn’t get Cgo working.  We’d prefer to have Go natively supported, but haven’t made much progress. A July 2018 post on NXP’s site indicated there is no internal NXP project to provide requested support for QorIQ processors: https://community.nxp.com/thread/480239.  We've also read the links on https://github.com/golang/go/issues/19075 and https://github.com/golang/go/issues/19074. Are there any recommendations for the best way to get this support added into the mainline?  We’re willing and able to supply hardware (e.g., multiple T4240RDB units), sweat equity (with guidance), and money in support of this effort!


I am also interested in knowing what is not working with gccgo. I keep seeing posts about gccgo not working on ppc64 but never see a bug report. gccgo allows you to select the specific instruction set to target using -mcpu, whereas golang does not allow that granularity for Power. That way you can select the correct instruction set and get the best performing code for that target.

It looks like the power8 and e6500 instruction set are very close and I believe code generated for ppc64 in golang should work on the e6500. According to binutils assembler, there are only a handful of power8 instructions that don't work on e6500 and I don't think those are generated by golang. Have you tried building a program cross-compiled for ppc64 and run it on your e6500? If you care about e5500 that is similar to power7 so that would be a problem for now.

However I think missing linker support for ppc64 big endian is a bigger issue, if you want to build something with cgo, such as applications like Docker or Kubernetes. The linker support for the ppc64 v1 ABI was never done (ppc64le is v2 ABI and that works). I don't really have a good idea of how much work that would be.

I'm also curious as to what distro this would be used with.


lab...@gmail.com

unread,
Aug 16, 2018, 10:46:27 AM8/16/18
to golang-dev
This comments applies only to golang. Linking with cgo should work fine with gccgo. There really is no concept of internal linking with gccgo, it is all external.

lab...@gmail.com

unread,
Aug 16, 2018, 5:11:49 PM8/16/18
to golang-dev


On Thursday, August 16, 2018 at 8:49:00 AM UTC-5, Lynn Boger wrote:


On Wednesday, August 15, 2018 at 4:48:26 PM UTC-5, mboillot wrote:

Hi everyone, we’re looking to run Go on NXP e5500/e6500 CPU’s.  We’ve had mixed success using gccgo in that we couldn’t get Cgo working.  We’d prefer to have Go natively supported, but haven’t made much progress. A July 2018 post on NXP’s site indicated there is no internal NXP project to provide requested support for QorIQ processors: https://community.nxp.com/thread/480239.  We've also read the links on https://github.com/golang/go/issues/19075 and https://github.com/golang/go/issues/19074. Are there any recommendations for the best way to get this support added into the mainline?  We’re willing and able to supply hardware (e.g., multiple T4240RDB units), sweat equity (with guidance), and money in support of this effort!


I am also interested in knowing what is not working with gccgo. I keep seeing posts about gccgo not working on ppc64 but never see a bug report. gccgo allows you to select the specific instruction set to target using -mcpu, whereas golang does not allow that granularity for Power. That way you can select the correct instruction set and get the best performing code for that target.

It looks like the power8 and e6500 instruction set are very close and I believe code generated for ppc64 in golang should work on the e6500. According to binutils assembler, there are only a handful of power8 instructions that don't work on e6500 and I don't think those are generated by golang. Have you tried building a program cross-compiled for ppc64 and run it on your e6500? If you care about e5500 that is similar to power7 so that would be a problem for now.

I found the doc for e6500 and see that it excludes some instructions from ISA 2.06, and several of those excluded instructions are generated by golang.
 

abu...@burnscorp.net

unread,
Aug 16, 2018, 7:40:43 PM8/16/18
to golang-dev
Hi,

I'm a coworker of mboillot and have been experimenting with gccgo on the e6500.  I'll give as many responses to questions as I can...

> Which version of Power is that?

>And you would want it to be Big-Endian, correct?
Yep. 

>And it runs a version of Linux, recent I hope?
We are running 4.1.X.  It's built with Yocto.  

>What was the problem of gccgo on that e5500/e6500?
I haven't been able to progress past this: https://github.com/golang/go/issues/23323

Ultimately, what we really want to do is run docker on a T4240  (based the e6500 ppc core).  Secondary to that, start rewriting our legacy C programs in GO.

Docker seems to be a complex go program which used to support gccgo fairly well in the past, but maybe not so well today.
Using the toolchain provided for the T4240, I have been able to create a go cross compiler and I am able to compile simple go programs which run.
Unfortunately, most complex go programs want to use CGO (docker included).   I would image I would need to use CGO in interface to c libraries for our rewrites too.

In going through all these hoops to try and get docker running, even if https://github.com/golang/go/issues/23323 is addressed, it will still be a pain with gccgo.  The build scripts all seem to assume the GC compiler is used.  I can image this could be true for a lot of the complex go packages we might want to use.

So for me,  it would be much better to have native support for the e6500.  I wouldn't have worry (in theory) about building packages.

So, looking for any advice on what it might take to get native support.  We are willing to invest some materials (T4240RDBs), time and money if it helps.
Or, if you have any better ideas on what it would take to run docker, I'm open to suggestions.  

Thanks,
Aaron

Ian Lance Taylor

unread,
Aug 16, 2018, 10:50:57 PM8/16/18
to abu...@burnscorp.net, golang-dev
On Thu, Aug 16, 2018 at 10:55 AM, <abu...@burnscorp.net> wrote:
>
>>What was the problem of gccgo on that e5500/e6500?
> I haven't been able to progress past this:
> https://github.com/golang/go/issues/23323

Did you see my suggestion on that issue to set the CC environment
variable to include the options you need?

Ian

abu...@burnscorp.net

unread,
Aug 16, 2018, 10:59:18 PM8/16/18
to golang-dev
I did.  I changed the CC env variable and it did not fix the error.
 

Aaron

Ian Lance Taylor

unread,
Aug 16, 2018, 11:08:32 PM8/16/18
to abu...@burnscorp.net, golang-dev
On Thu, Aug 16, 2018 at 7:59 PM, <abu...@burnscorp.net> wrote:
> I did. I changed the CC env variable and it did not fix the error.

Could you reply to the issue saying exactly what you did and exactly
what happened? At the moment I don't understand how that could fail.
Thanks.

Ian


> On Thursday, August 16, 2018 at 10:50:57 PM UTC-4, Ian Lance Taylor wrote:
>>
>> On Thu, Aug 16, 2018 at 10:55 AM, <abu...@burnscorp.net> wrote:
>> >
>> >>What was the problem of gccgo on that e5500/e6500?
>> > I haven't been able to progress past this:
>> > https://github.com/golang/go/issues/23323
>>
>> Did you see my suggestion on that issue to set the CC environment
>> variable to include the options you need?
>>
>> Ian
>

ma.j...@zte.com.cn

unread,
Oct 21, 2018, 1:14:19 AM10/21/18
to golang-dev


On Thursday, August 16, 2018 at 5:48:26 AM UTC+8, mboillot wrote:

Hi everyone, we’re looking to run Go on NXP e5500/e6500 CPU’s.  We’ve had mixed success using gccgo in that we couldn’t get Cgo working.  We’d prefer to have Go natively supported, but haven’t made much progress. A July 2018 post on NXP’s site indicated there is no internal NXP project to provide requested support for QorIQ processors: https://community.nxp.com/thread/480239.  We've also read the links on https://github.com/golang/go/issues/19075 and https://github.com/golang/go/issues/19074. Are there any recommendations for the best way to get this support added into the mainline?  We’re willing and able to supply hardware (e.g., multiple T4240RDB units), sweat equity (with guidance), and money in support of this effort!


Hi mboillot , we are have successfully build docker on ppc64(e6500 in fact) using golang 1.7.6  several months ago. We have finished some basic tests for that docker, and it looked fine.
We are trying to  port our patches to the trunk. But it seems that this work need more resources than we expected. We will be appreciated if you could provide some help,

ma.j...@zte.com.cn

unread,
Oct 21, 2018, 1:14:21 AM10/21/18
to golang-dev
NXP have sold many e6500 cores, and I believe many companies (other than ZTE) are still using these cores.
I do not understand why they keep silent in https://github.com/golang/go/issues/19074...
And I agree with you that dropping support for older BE ISAs is a mistake...

ma.j...@zte.com.cn

unread,
Oct 21, 2018, 1:14:27 AM10/21/18
to golang-dev
We have build docker using both gccgo(gcc8) and golang(1.7.6).
The gccgo version have two problem.
First, it have  memory leaks( a bug in split stack pointer process).
Second , it takes many times longer time(10x on our env) to start.

The second problem is very hard, so we decided to use golang finally.
Reply all
Reply to author
Forward
Message has been deleted
0 new messages