On Thu, Dec 12, 2019 at 5:17 PM <
the.n...@gmail.com> wrote:
> I am late to the thread, but am considering a port to HPE NonStop. The platform is runs on x86 with a POSIX personality. Data is maintained big-endian. I do know the guts of the machine very well, so runtime should not be an issue, but assembly is not actually available - but this is x86 so I might be able to MacGyver something. The big difficulty is that GCC does not port to the platform. I am wondering where I should actually start on this given that there really isn't an apparent similar model to base this on, nor what the values even for GOOS/GOARCH should be.
Its big-endianness is actually emulated by compiler, right?
Then there will need to be some Go compiler support as well. Unless we
still run Go program with little endian data variables, and only
translate data endianness at syscall (and cgo) boundaries. If there is
not gcc support, then likely cgo won't be supported.
On Thu, Dec 12, 2019 at 9:50 PM Ian Lance Taylor <
ia...@golang.org> wrote:
> I guess the GOARCH value would be amd64be. I don't know what the GOOS
> value would be, but it doesn't matter much.
The problem is that the processor really is running in little endian
mode, so really GOARCH should still be amd64, not amd64be.
But I agree, the actual GOOS and GOARCH value is not very important at
this stage. Once the port works and is ready for integration, we can
pick one based on the changes (whether it changes the compiler
generate BE values or not should determine whether it's GOARCH=amd64be
or amd64.)