[golang-dev] how to port golang to a new architecture

[r***@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 : [phone]
1 rue de Provence - 38432 Échirolles - France
www.atos.net<https://mail.ad.bull.net/owa/redir.aspx?C=PvphmPvCZkGrAgHVnWGsdMcDKgzl_dEIsM6rX0g4u4v8V81YffzBGkWrtQeAXNovd3ttkJL8JIc.&URL=http%3a%2f%2fwww.atos.net%2f>
________________________________
De : golang-***@googlegroups.com <golang-***@googlegroups.com> de la part de ***@gmail.com <***@gmail.com>
Envoyé : mardi 19 juin 2018 11:14:09
À : golang-dev
Objet : [golang-dev] how to port golang to a new architecture

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~

--
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<mailto:golang-dev+***@googlegroups.com>.
For more options, visit https://groups.google.com/d/optout.

['Keith Randall' via golang-dev]

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?

Post by 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 : [phone]
1 rue de Provence - 38432 Échirolles - France
www.atos.net
<https://mail.ad.bull.net/owa/redir.aspx?C=PvphmPvCZkGrAgHVnWGsdMcDKgzl_dEIsM6rX0g4u4v8V81YffzBGkWrtQeAXNovd3ttkJL8JIc.&URL=http%3a%2f%2fwww.atos.net%2f>
------------------------------
*Envoyé :* mardi 19 juin 2018 11:14:09
*À :* golang-dev
*Objet :* [golang-dev] how to port golang to a new architecture
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~
--
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
For more options, visit https://groups.google.com/d/optout.
--
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
For more options, visit https://groups.google.com/d/optout.

[r***@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写道

Post by 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 : [phone]
1 rue de Provence - 38432 Échirolles - France
www.atos.net
<https://mail.ad.bull.net/owa/redir.aspx?C=PvphmPvCZkGrAgHVnWGsdMcDKgzl_dEIsM6rX0g4u4v8V81YffzBGkWrtQeAXNovd3ttkJL8JIc.&URL=http%3a%2f%2fwww.atos.net%2f>
------------------------------
*Envoyé :* mardi 19 juin 2018 11:14:09
*À :* golang-dev
*Objet :* [golang-dev] how to port golang to a new architecture
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~
--
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
For more options, visit https://groups.google.com/d/optout.

[Ian Lance Taylor]

Post by r***@gmail.com
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.

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

Post by Aram Hăvărneanu
I've done many ports now, so the strategy I use
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

[r***@gmail.com]

totally agreed

圚 2018幎6月21日星期四 UTC+8䞊午4:35:26Matt Layher写道

Post by 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.

Post by Aram Hăvărneanu
I've done many ports now, so the strategy I use
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

[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 : [phone]
1 rue de Provence - 38432 Échirolles - France
www.atos.net<https://mail.ad.bull.net/owa/redir.aspx?C=PvphmPvCZkGrAgHVnWGsdMcDKgzl_dEIsM6rX0g4u4v8V81YffzBGkWrtQeAXNovd3ttkJL8JIc.&URL=http%3a%2f%2fwww.atos.net%2f>
________________________________
De : golang-***@googlegroups.com <golang-***@googlegroups.com> de la part de Matt Layher <***@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.

On Wednesday, June 20, 2018 at 9:54:01 AM UTC-4, Aram Hãvãrneanu wrote:
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

--
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<mailto:golang-dev+***@googlegroups.com>.
For more options, visit https://groups.google.com/d/optout.

[r***@gmail.com]

Thank you so much for this, Aram :)

圚 2018幎6月20日星期䞉 UTC+8䞋午9:54:01Aram Hăvărneanu写道

Post by Aram Hăvărneanu
I've done many ports now, so the strategy I use
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

[Josh Bleecher Snyder]

Post by r***@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?

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

Post by r***@gmail.com
thx a lot~
--
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
For more options, visit https://groups.google.com/d/optout.

[r***@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.

[Josh Bleecher Snyder]

Post by r***@gmail.com
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

[r***@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写道

Post by Josh Bleecher Snyder

Post by r***@gmail.com
Thank you all for the information, and we are planning to port golang to

a

Post by r***@gmail.com
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