go/build: add more GOARCH values?

[bradfitz]

(Moving discussion in https://go-review.googlesource.com/c/35031/ to here)

Should we add m68k and alpha to gc's GOARCH list?

/cc @ianlancetaylor @minux

[minux]

https://golang.org/cl/9644 reserves most of the GOARCHes.

At that time, my understanding of the rationale is that it's possible that someone will want to implement support for that GOARCH in gc in the future.

Therefore I left out: alpha: because it's no longer commercially available. ia64 (Itanium): because it's too hard to write a reasonably good compiler for.

m68k arguably falls into the first category. I know Motorola/Freescale/NXP still produces ColdFire processors whose ISA is simplified from MC68000 ISA, so perhaps I couldn't say m68k is no longer available, but the market is fairly small (and NXP might eventually discontinue the produce line.)

In CL 35031, it's argued that gccgo supports alpha and m68k, we should add those two.

It's fine to add those two, but I wonder where should we draw the line?

For example, should we add vax here? NetBSD still runs fine on vax, and it's possible that gccgo might get netbsd/vax support in the future (if someone is willing to port libffi.)

The problem is bigger for GOOS as porting Go to a new OS is generally much easier than porting to a new architecture. So even using a bar as high as requiring one complete implementation in some toolchain is not enough.

[ianlancetaylor]

I changed the title from GOOS to GOARCH.

If Go continues to catch on, we have to realistically consider the possibility that people will expect it to run on every architecture that supports GNU/Linux or NetBSD. That is quite a few architectures that we don't currently list: alpha, arc, avr32, blackfix, c6x, cris, frv, h8300, hexagon, ia64, m32r, m68k, metag, microblaze, mn10300, nios2, openrisc, parisc, score, sh, tile, unicore32, vax, xtensa. And of course new ones appear from time to time.

I think we need to drop the idea of knowing all possible GOARCH values., and just rely on +build constraints for new ports.

[minux]

That is, no file name GOOS_GOARCH support, only explicitly +build lines?

What about binary syso files?

I was thinking the opposite way, add a way to denote regular build tags in file names, so that we don't need to have a full GOOS / GOARCH list.

[bradfitz]

Sounds like we're not going to add more well-known GOOS/GOARCH values and be more explicit going forward. Closing.

[glaubitz]

Just as a heads-up: There is still a very active community on these old architectures in the field of retro-computing, especially around the m68k architecture.

There are still people and small companies making new hardware and there are also new, FPGA-based CPU designs being released. There are, for example, Amigas accelerators with 68060-compatible CPUs which are clocked with 600 MHz and more.

In Debian, we support a large number of architectures, including obscure ones and the vast majority of packages build just fine. Debian unstable with the latest kernel runs perfectly on old m68k hardware.

I am currently hacking on gccgo on m68k and sh. The former has alignment issues which makes Go binaries crash while the latter has not been added to libgo yet, I already sent a patch for sh though.