On Wed, Jan 10, 2018 at 6:30 AM, John Paul Adrian Glaubitz <glaub...@physik.fu-berlin.de> wrote: > On 01/10/2018 03:25 PM, Ian Lance Taylor wrote: >> >> Thanks. I finally took a look at this. I don't know much about SH, >> but I don't think we want to add each SH variant as a separate GOARCH >> value. As you can see from the list you modified in >> ibgo/go/go/build/syslist.go, the difference between GOARCH values is >> essentially the calling convention. There are many different kinds of >> x86 processors, but since the only calling convention difference is >> between 32-bit and 64-bit, the list has only 386 and amd64. Similarly >> it seems to me we should have only sh and shbe in the list for SH >> processors. > > > My reasoning is that gcc itself differentiates between those different > SH targets, i.e. there is a sh3, a sh4 target and the big-endian variants > of these targets. There aren't different x86_64 targets in gcc though. > > Furthermore, as you can see, sh3 and sh4 also have different cacheline > sizes, for example: > >> >> https://go-review.googlesource.com/c/gofrontend/+/84555/1/libgo/configure.ac > > > In total, we have four different SH targets.
The main purpose of a GOARCH value is to specify build targets, which are the +build lines seen in files like libgo/go/internal/syscall/unix/getrandom_linux_mipsx.go. They also appear in file names. It seems to me unlikely that it will ever be necessary to distinguish SH3 and SH4 when choosing which files to build. In the past we've started off with too many GOARCH values for a specific processor, and backed off later. I'd prefer to do it the other way around now: start off with a few possible, and add more if really required. The fact that GCC supports multiple SH configurations is an interesting point, but that is also true of, say, MIPS, but we're not replicating all the MIPS choices in the GOARCH list. Ian
