go/build: add more GOARCH values? #18586
Comments
|
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
changed the title
|
I changed the title from 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 |
|
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.
|
|
Sounds like we're not going to add more well-known GOOS/GOARCH values and be more explicit going forward. Closing. |
|
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. |
(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
The text was updated successfully, but these errors were encountered: