how to port golang to a new architecture

[raphae...@gmail.com]

I know there's the porting policy, but there seems to be no technical materials on how to port golang to a new architecture.

Or am I wrong?

I read from source that quite some work needs to be done for src/cmd and src/runtime, and we should finally pass all tests in test, but is there any detailed roadmap or howto?

thx a lot~

[REIX, Tony]

Hi,

We are porting golang to AIX.

We used our port of GCC 8.1 Go to AIX for bootstrapping and we used the work done by IBM Linux/Power about the Go assembler for PPC64 machines.

So, you need a Go compiler for bootstrapping. Either GCC Go, or an old golang written in C (v1.4 if I'm correct).

Easier if the OS is Linux.

A huge work. Requiring skills about the operating system and the assembler.

Regards,

Cordialement,

Tony Reix

ATOS / Bull SAS
ATOS Expert
IBM Coop Architect & Technical Leader

Office : +33 (0) 4 76 29 72 67

1 rue de Provence - 38432 Échirolles - France

www.atos.net

---

De : golan...@googlegroups.com <golan...@googlegroups.com> de la part de raphae...@gmail.com <raphae...@gmail.com>
Envoyé : mardi 19 juin 2018 11:14:09
À : golang-dev
Objet : [golang-dev] how to port golang to a new architecture

 

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Keith Randall]

There's no explicit porting documentation.  You can follow the issues from another port, e.g. webassembly https://github.com/golang/go/issues/18892

What architecture are you targeting?

[Josh Bleecher Snyder]

I’m afraid not. Is there a particular architecture you have in mind?

[raphae...@gmail.com]

Hi,

Thank you all for the information, and we are planning to port golang to a mips-alike architecture.

Since there's no explicit doc on the subject, we'll first bootstrap and then make progress in src/cmd and src/runtime.. as we have planned before, and hope everything moves smooth.

[raphae...@gmail.com]

Hi,

As far as I can infer from the install-source.html, we don't need to modify gc 1.4, right?

Since we always want to port the latest golang version and 1.4 is for bootstrap only, do we need to port both 1.4 and 1.10 (the latest version for now) to the new architecture? This might be a double work, as we think.

在 2018年6月19日星期二 UTC+8下午9:30:29，REIX, Tony写道：

[Ian Lance Taylor]

On Tue, Jun 19, 2018 at 9:05 PM, <raphae...@gmail.com> wrote:
>
> As far as I can infer from the install-source.html, we don't need to modify
> gc 1.4, right?
>
> Since we always want to port the latest golang version and 1.4 is for
> bootstrap only, do we need to port both 1.4 and 1.10 (the latest version for
> now) to the new architecture? This might be a double work, as we think.

You don't want to port 1.4. Instead, use src/bootstrap.bash. That
will let you cross-compile from amd64 or any other supported platform.
Someone who wants to build all the way from source will have build
1.4, use that to build a sufficiently new version of Go on amd64 or
whatever, and use that to bootstrap onto your platform.

Ian

[Aram Hăvărneanu]

I've done many ports now, so the strategy I use
is this (very simplified):

1. Add GOOS/GOARCH support to the toolchain

2. Add some support for GOARCH in cmd/internal/obj
3. Add some support for GOARCH in cmd/asm
4. Add some support for GOOS/GOARCH in cmd/link

5. Iterate through 2-3-4 until you can produse some kind
of binaries from assembly files. Depending on the specifics
of GOOS/GOARCH you might, or might not need to use external
linking.

6. Once you can produce binaries, thoroughly test them (link
just assembly programs, without runtime). Basically make
sure the low-level toolchain works.

7. Start working on the Go compiler for GOARCH.

8. Write a minimal alternative runtime for Go. The runtime
is much too complicated as a first test Go program. Basically
write your own runtime in assembly that is just stubbed
out, but can run a good bulk of the programs in go/test.

9. Once that works well enough, start using the real runtime.
This requires implementing a lot of assembly, but you can
use the lessons learned from #8.

10. Make all the tests in go/test work.
11. Make all the stdlib tests work. You are still working
amd64 now, and executing on GOARCH with go_GOOS_GOARCH_exec.

12. Run bootstrap.bash

13. Move over the artifacts on GOOS/GOARCH machine.

14. Make sure make.bash works. You will still likely have
to fix problems to make this N-generation compiler work.

15. Make sure all.bash works.

16. Done.

As you can see, steps 1-14 are done on amd64 (or some other supported
platform), and only step 15 is done on the target architecture.

--
Aram Hăvărneanu

[Matt Layher]

I apologize that I can't contribute more to the question at hand, but Aram, I would personally love to see an in-depth write-up of the porting process that could be later added to the project's official documentation.

[raphae...@gmail.com]

Thank you so much for this, Aram :)

在 2018年6月20日星期三 UTC+8下午9:54:01，Aram Hăvărneanu写道：

[raphae...@gmail.com]

totally agreed

在 2018年6月21日星期四 UTC+8上午4:35:26，Matt Layher写道：

[REIX, Tony]

Probabaly that such a "porting process" document should also include a description of the solution we had to take when porting golang to AIX, using the port of GCC Go.

Regards,

Cordialement,

Tony Reix

ATOS / Bull SAS
ATOS Expert
IBM Coop Architect & Technical Leader

Office : +33 (0) 4 76 29 72 67

1 rue de Provence - 38432 Échirolles - France

www.atos.net

---

De : golan...@googlegroups.com <golan...@googlegroups.com> de la part de Matt Layher <mdla...@gmail.com>
Envoyé : mercredi 20 juin 2018 22:35:26
À : golang-dev
Objet : Re: [golang-dev] how to port golang to a new architecture

 

I apologize that I can't contribute more to the question at hand, but Aram, I would personally love to see an in-depth write-up of the porting process that could be later added to the project's official documentation.

Aram Hãvãrneanu

[Josh Bleecher Snyder]

> Thank you all for the information, and we are planning to port golang to a
> mips-alike architecture.

Is the architecture private? (That is, is it possible to publicly
acquire hardware, or will it be at some point?) And if it is private,
do you plan to upstream your port? If so, I’m not sure what the policy
is about that. I think it is worth having such discussions earlier
rather than later.

-josh

[raphae...@gmail.com]

The architecture is now private, but we have not decided yet whether to make it public or not.

My personal opinion is to to make it publicly available later, and we'll try our best to make it ready to be accepted by the upstream.

在 2018年6月22日星期五 UTC+8上午1:14:21，Josh Bleecher Snyder写道：

[the.n...@gmail.com]

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.

Regards,

Randall

[Ian Lance Taylor]

On Thu, Dec 12, 2019 at 2:18 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.

Currently supporting cgo (https://golang.org/cmd/cgo) requires GCC.
But if you don't care about cgo you don't need to use GCC. You can
build everything in Go without GCC or any C code at all.

I guess the GOARCH value would be amd64be. I don't know what the GOOS
value would be, but it doesn't matter much.

Ian

[minux]

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.)