Comment 1 by laboger:

Last sentence should be "I'm not stating an opinion.... "

Comment 2:

Labels changed: added repo-main, release-go1.5.

Status changed to Accepted.

Comment 3:

i still like power64/power64le as that's how ibm calls the
architecture, and we don't always agree with gcc in terms
of goarch.
for example, 386, amd64, amd64p32, arm64.
iant? do you agree? i will send CL to gccgo if you agree.

Comment 4 by laboger:

I was told by Steve Munroe that there is an issue with the use of the name power64
because Power is an IBM brand name.  If you want more details I can ask him to provide
them.
Right now we use both ppc64 and powerpc64, so it would be nice not to add another
variation.  Also I don't think the fact that it is inconsistent for other platforms is a
legitimate reason to make it inconsistent for powerpc64 too.  Seems like you'd want all
the GOARCH values to be same for gc and gccgo.

Comment 5:

yes, i propose both gc and gccgo use power64 and power64le.
we need a way to differentiate big/little endian when generating
the code, so we need two goarches.
we use power64 to refer to precisely the same that ibm refers to,
so why that's not allowed?

Comment 6:

note: PowerPC is also a trademark of IBM, so i think
the trademark shouldn't affect us.

Comment 7 by laboger:

Last sentence should be "I'm not stating an opinion.... "

Comment 8 by peter.e.bergner:

We use powerpc64 and powerpc64le for gcc target triples.  Can we use those?  Otherwise,
my second choice would be ppc64 and ppc64le, since those are also used in some other
projects (LLVM?).  As far as I am aware, no one uses power64 and power64le.

Comment 9:

no one uses amd64p32 either. so there is precedent using Go
specific GOARCHes.

Comment 10 by sjmunroe52:

POWER is brand name for series for chip designs (micro architecture) designed by IBM for
servers. It does not apply to Chips produced by Freescale (e6500) or P.A. Semi (PA6T).
PowerPC was the official name of the Instruction Set Architecture (it is now PowerISA as
of V2.03) and so applies to ISA complaint chips (includes Freescale and PA Semi)
powerpc[64] and ppc[64] are widely accepted names for the architecture in the GNU/Linux
community. When generating code you want the architecture name at the top level.
power with a number suffix (ie power7 power8) should only be used to designate a
specific POWER server chip (micro-architecture).

Comment 11 by peter.e.bergner:

> no one uses amd64p32 either. so there is precedent using
> Go specific GOARCHes.
Maybe so, but since GC support for POWER doesn't exist modulo with your new patches,
there's no reason to use values that are different from what other packages use.

Comment 12:

gccgo might support x32 before we added amd64p32, but
that doesn't mean we must use x32 in gc.
according to the latest ISA, the ISA itself is called
Power, and as that document also call it "Power Architecture",
i see no reason we can't use power64 and power32 to
designate 64/32-bit GOARCH. Note: there is no need to
use the same architecture name as others (gcc/llvm/binutils)
do because gc is a completely separate toolchain.
we are not talking about the chip here, so i don't think
people will confuse it with IBM's microarchitecture (plus
we are not even close to Power32/Power64 now)
and btw, power64 is not a trademark, but powerpc is.

Comment 13:

Minux, why not use the names that the IBM guys are suggesting?  And why not use the
names that other people use?  What's the advantage of being different?  Why is power64
better?

Comment 14:

power64 is consistent with other GOARCHes,
and also the latest ISA document called the
ISA "Power ISA", not ppc ISA or powerpc ISA.
i think the names ppc or powerpc are chosen
because of historical reasons (gcc internally
even use rs6000 for ppc)
now that ibm named their ISA "Power", why not
use the official name?

Comment 15:

Good work, Minux. The port must be sufficiently far along that the only thing to
complain about is the name. :) More seriously, why is it important to use the outdated
name that GCC uses? It's the Power architecture, hence power and power64. Just like arm.

Comment 16:

Gcc/binutils names have always been very different from gc names. That's perfectly fine,
and it will always continue to be true because of the pigeon hole principle. Let's not
bikeshed this. Historically, GOARCH has been Plan 9's $objtype, and $objtype for 9c has
been power64 (objtype for qc has been power). Since the toolchain can now also do
little-endian, power64le seems fine. All these are internally consistent and consistent
with the ISA manual

Comment 17:

> I was told by Steve Munroe that there is an issue with the use of
> the name power64 because Power is an IBM brand name.  If you want
> more details I can ask him to provide them
I'm pretty sure Windows and Solaris are brand names too.

Comment 18 by sjmunroe52:

There is difference between a trademark on a architect and brand name for a hardware
product.
IBM wants you to use the trademarked Architecture name for enabled software, and it Ok
to apply it to the all complaint implementations, include CHIPs from other companies.
It is NOT OK to apply IBM's Brand Name to chips from other companies.
So you if you don't want to use powerpc then use the new powerISA (TM). But please don't
use power or power64.

Comment 19:

are you suggesting that we set
GOARCH="powerISA (TM)"
?
perhaps you're talking about something else, for example,
documentation for the port (and in that case, i'm open to
whatever adjustment you want), but we are talking about
$GOARCH and runtime.GOARCH, which is a string/environment
variable to tell the toolchain which compiler and linker
it should use.
as aram pointed out, Plan 9 has been using power64
for some time, see http://plan9.bell-labs.com/sources/plan9/power64/, even
though the official plan 9 distribution
doesn't include the 9c toolchain.

Comment 20 by sjmunroe52:

I am suggesting that if you don't like powerpc you can use powerisa because is the
TradeMark for architecture and not the Brand name for the POWER servers.
I don't think plan9 counts in this discussion. They are messing with IBM's Brand
identity, a bad idea.
GCC and GNU in general are consistent with powerpc.
gcc -E -dD hello.c | grep power
#define __powerpc__ 1
#define __powerpc64__ 1
That is what every one would expect.

Comment 21 by peter.e.bergner:

minux wrote:
> yes, i propose both gc and gccgo use power64 and power64le.
I agree gc and gccgo should use a common GOARCH value, but I don't think
changing the gccgo GOARCH value is a good idea, since there are already
gccgo compilers released and being used in distros (Ubuntu, etc.) that
use the ppc64 value.  Since there is no released gc compiler we have to
be compatible with, why not change gc to match gccgo's ppc64 value?
You also mention in another comment that gc and gccgo don't have to
agree on the GOARCH value and although that is true, I believe it is
highly desirable that they do match and since ppc64 gc support has not
been released yet, we can easily make that happen by having gc match
gccgo's ppc64 GOARCH value.
If gc and gccgo don't match, then that just make porting packages that
rely on GOARCH that were developed on one compiler all that much harder
to get working on the other.  If we pick a common value, then that is
just one less thing to worry about.
> we need a way to differentiate big/little endian when generating
> the code, so we need two goarches.
I agree that we need to differentiate between ppc64 big-endian versus
little-endian.  I thought someone (Ian?) mentioned that we should have
the same GOARCH value for both big-endian and little-endian.  If that
is the case, what would be the mechanism to differentiate between the
two?  A different macro like GOENDIAN or ???  I'll state I'm not against
a different GOARCH value for little-endian versus big-endian, but can
be persuaded either way.

Comment 22:

we will need to change gccgo's GOARCH
anyway because it uses ppc64 for both
endians.
I don't like to add another mechanism
to set endian.
similarly, the upcoming 64-bit arm port
will have the same problem. gccgo will
to change to match gc's if we want to
maintain consistent GOARCH.
Also, if we have a mips gc port, then
I'd expect that GOARCH be mips, mips64
and mips64p32 for o32, n64 and n32 abi.
again, gccgo needs to change to match.

Comment 23:

I don't mind changing gccgo's GOARCH value.
I'm still inclined to listen to IBM's suggestions for GOARCH values rather than Plan 9
suggestions.  The fact that we have in the past used unusual GOARCH names is not a
reason to use unusual ones going forward.
The problem with using different GOARCH values based on endianness is that file names
become awkward.  You can no longer name a file syscall_powerpc64.go, because it will
only be used on big-endian, not little-endian.  It's quite normal to want to have build
tags that are processor-specific.  It's quite unusual, in fact, it never happens, to use
a build tag that is endian-specific.  So why do we want to distinguish endianness in the
GOARCH value?

Comment 24:

we need some way to embed (into cmd/go)
and set the endianness for the build
using GOARCH is the easiest way to do
without another mechanism.
Perhaps we do need another mechanism,
think all three mips GOARCHes.
Currently the 9g port used the convention
that files are named file_power64x.go
and have both GOARCHes are build tags.

Comment 25 by laboger:

Based on the last two comments, are you leaning toward keeping the current gccgo GOARCH
value, using ppc64 for both BE & LE?  Meaning no changes needed for gccgo but gc will
change to use ppc64 for both and find another way to determine endianness?

Comment 26 by laboger@linux.vnet.ibm.com:

Is there any update on this issue with respect to gccgo?  The team working on Docker for
Power believe there should be different GOARCH values for ppc64 and ppc64le and would
like to know when there would be a change for that or if a patch should be submitted to
set it.

Comment 27:

Based on the discussion on golang-dev, the GOARCH values will be "ppc64" and "ppc64le".
Both the gc toolchain and gccgo will need to be updated. For the gc toolchain, this will
happen in the 1.5 release (the first with 64-bit Power support).

Comment 28:

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

Comment 29:

This issue was closed by revision 09d92b6.

Status changed to Fixed.