Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

all: port to linux/loong64 #46229

Closed
XiaodongLoong opened this issue May 18, 2021 · 156 comments
Closed

all: port to linux/loong64 #46229

XiaodongLoong opened this issue May 18, 2021 · 156 comments
Labels
arch-loong64 Issues solely affecting the loongson architecture. Proposal Proposal-Accepted Proposal-FinalCommentPeriod
Milestone

Comments

@XiaodongLoong
Copy link
Contributor

XiaodongLoong commented May 18, 2021

Hi community,

I am from Loongson company (R & D CPU), and we have developed a new RISC CPU instruction architecture named LoongArch.

We have successfully ported linux/loongarch64 in Go version 1.15.6, and want to submit some patches to the Go community to support this port.

To support linux/loongarch64 port, we have a plan:
(1) provide a builder machine (Loongson 3A5000/2.2GHz,debian-buster / 4.19 linux-kernel) remotely.
(2) submit the patches in August (after Go 1.17 release).
(3) complete the submission and review of all patches by November and be stable state.
(4) maintain linux/loongarch64 port and builder machine for a long time.

@XiaodongLoong
Copy link
Contributor Author

CC @rsc @rsto @ianlancetaylor

@dmitshur dmitshur added this to the Proposal milestone May 18, 2021
@dmitshur dmitshur changed the title all: port to linux/loongarch64 proposal: all: port to linux/loongarch64 May 18, 2021
@dmitshur
Copy link
Contributor

CC @golang/release.

@mengzhuo
Copy link
Contributor

I think maybe "loong64"/"la64" is more appropriate since "loongarch64" is simply too loong ( pun :)

@ianlancetaylor ianlancetaylor added this to Incoming in Proposals (old) May 19, 2021
@ianlancetaylor
Copy link
Contributor

This seems fine to me. Can you provide links to a description of the architecture?

I take it that you are suggesting a GOARCH value of loongarch64.

@dr2chase
Copy link
Contributor

I prefer not "la64" because it might be confused with "IA64" which is the usual acronym for Intel's Itanium.
I think "loong64" is good; a GOARCH value that itself contains the substring "arch" is redundant, we don't do that for any other.

@rsc
Copy link
Contributor

rsc commented May 19, 2021

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

@rsc rsc moved this from Incoming to Active in Proposals (old) May 19, 2021
@XiaodongLoong
Copy link
Contributor Author

XiaodongLoong commented May 20, 2021

@ianlancetaylor We will provide an architecture instruction manual in the near future and I will update a link on this issue. As you said we use GOARCH value of loongarch64 in our Go version 1.15.6.

@mengzhuo @dr2chase Thanks for your suggestion, we will consider it.

Thank you all.

@tklauser
Copy link
Member

It seems like the instruction is MIPS64 compatible? How does Loongson differ from MIPS64?

I see that e.g. in GCC, in binutils and in the Linux kernel the architecture is handled as a variant of the MIPS/MIPS64 architecture. Could we do this in a similar way for Go and avoid having to introduce a separate GOARCH?

@XiaodongLoong
Copy link
Contributor Author

@tklauser The Loongson you said is not the LoongArch. Loongson is an extension of MIPS64 instruction set, but LoongArch is not. LoongArch is a new RISC CPU instruction architecture.

@tklauser
Copy link
Member

@XiaodongLoong thanks for clarifying

@XiaodongLoong
Copy link
Contributor Author

XiaodongLoong commented May 21, 2021

The description of LoongArch architecture: https://github.com/loongson/LoongArch-Documentation/releases

@rsc
Copy link
Contributor

rsc commented May 26, 2021

Are people happy with GOARCH=loong64?

If the builder will be at Loongson in China, do you know whether it will be able to connect to our build infrastructure running in Google data centers? The remote builder connects to Google's servers; Google's servers never dial back in the other direction.

@mengzhuo
Copy link
Contributor

Are people happy with GOARCH=loong64?

If the builder will be at Loongson in China, do you know whether it will be able to connect to our build infrastructure running in Google data centers? The remote builder connects to Google's servers; Google's servers never dial back in the other direction.

GOARCH=loong64 sounds good to me.

There are three reverse builders that in China up and running for about 2 years:

  • host-linux-amd64-wsl (2)
  • host-linux-mipsle-mengzhuo

@xen0n
Copy link
Member

xen0n commented May 27, 2021

I second the loong64 suggestion, considering e.g. we already use arm64 for that architecture officially named aarch64.

@XiaodongLoong
Copy link
Contributor Author

XiaodongLoong commented May 31, 2021

The proposal on the GOARCH=loong64 is entirely feasible in a technology perspective. But this is related to the business brands, intellectual property and so on. We have launched an internal discussion on this issues and I will update the discussion results as soon as possible.

Thanks.

@mengzhuo
Copy link
Contributor

I don't see why GOARCH=loong64 is related to IP or brand. What it matter is conciseness and correctness ( el vs le)

Intel x86_64 = amd64
Arm v8 (aarch64) = arm64

Microprocessor without Interlocked Pipelined Stages = MIPS -> mips
Performance Optimization With Enhanced RISC – Performance Computing = PPC -> ppc

Since Loongarch64 is short for "Loongson architecture version 64bit ", I think GOARCH=loong64 is good enough for this very new RISC architecture.

@rsc
Copy link
Contributor

rsc commented Jun 2, 2021

Thanks @XiaodongLoong. We will wait for your response.

@XiaodongLoong
Copy link
Contributor Author

@rsc After a week of internal discussion, we combine the community's proposal with our reality, and finally produced discussion results with difficulty. Considering brand promotion, registration of trademark and the unity of naming, we want to continue to use GOARCH=loongarch64.

@mengzhuo @xen0n Thank you for your advice, sincerely.

@tduslost
Copy link

tduslost commented Jun 5, 2021

happy with GOARCH=loong64

@dongzerun
Copy link

happy with GOARCH=loong64 too

@bigwhite
Copy link

bigwhite commented Jun 5, 2021

prefer GOARCH=loong64

@xen0n
Copy link
Member

xen0n commented Jun 5, 2021

I'm sorry but the "brand promotion" argument is just way off limits. Do you really consider "impressing" people with the 9-letter word loongarch appearing verbatim everywhere a good marketing strategy? Or that even an enum value never used in front of the general public should be trademarked? While we're at it, in order to better highlight the brand and to comply with trademark law, do we optionally accept GOARCH=LoongArch:tm:64 too?

Non-technical points aside, the point @dr2chase brought forward earlier is valid, and the "discussion result" fails to provide justification as to why the current convention should absolutely be broken. The Go language and community has a reputation for being rather opinionated than most others; for GOARCH values, apart from aarch64 -> arm64 we also have mipsel -> mipsle, x86_64 -> amd64 for example. Go never decides on a value just because the GNU or LLVM triple says so, much less a vendor's unilateral statement.

Finally, remember most community members not part of the full-time Go team are volunteers, devoting their free time to Go, and in this thread, LoongArch, without rewards. Appearing grateful to community input and contributions but in fact pushing one's own agenda without changes or clear communication is not good, and the softer part of our hearts can certainly feel that. Not placing your trademark in GOARCH is perfectly fine, people will still know of the brand, and a lot of typing would be saved. 😂

@willliu
Copy link

willliu commented Jun 6, 2021

One shortcoming to use loong64 instead of loongarch64 is the potential future confusion, since loongarch64 seems intended used for ISA name, linux kernel, java runtime, compiler and everything.

@xen0n
Copy link
Member

xen0n commented Jun 6, 2021

One shortcoming to use loong64 instead of loongarch64 is the potential future confusion, since loongarch64 seems intended used for ISA name, linux kernel, java runtime, compiler and everything.

And no one seems to mistake arm64 or amd64; users are smart enough to figure out things. Go, or any other project not using target triples, is not obliged to follow each other; what's important is following respective established conventions. IOW, “入乡随俗”——“when in Rome, do as Romans do”.

The argument against GOARCH=loongarch64 is never meant to be delibrate opposition or personal attack; instead it's purely technical and about convention and consistency.

Also, a kind reminder to @mengzhuo : maybe calm down a bit and don't start to call names? We have no hard evidence that @willliu is actually @XiaodongLoong , so it's probably not time to make this kind of statement.

However, I agree the account is suspicious, because the LoongArch ports of Linux and Java are never sent upstream, and the toolchain sources are withdrawn after only a short time, I think.

gopherbot pushed a commit to golang/build that referenced this issue May 20, 2022
The loong64 port is now complete with tests passing.

For golang/go#46229.

Change-Id: Ie0c0aaf461c7ef019125716b35594da12b0a7492
Reviewed-on: https://go-review.googlesource.com/c/build/+/407506
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
@prattmic
Copy link
Member

prattmic commented May 20, 2022

Congrats on getting the port in!

@XiaodongLoong it was noted in https://go.dev/cl/407507 that the coordinator expects 5 loong64 builders, but there are only 2 running. This should be resolved one way or another: fix the missing builders if we really expect 5, or update builders.go if only 2 are expected.

@XiaodongLoong
Copy link
Contributor Author

@prattmic Thanks!

About loong64 builders, we file a discussion to make a decision.

And thanks erveryone who contributed to loong64 port. ❤️

@XiaodongLoong
Copy link
Contributor Author

@prattmic
Per the observation and discussion in recent days, we think 3 builders might be able to meet the requirements of the building. If it is not enough in the future , we’ll add more. So we'll update the "ExpectNum" to 3.

Thanks! ❤️

@gopherbot
Copy link

Change https://go.dev/cl/407935 mentions this issue: dashboard: update ExpectNum to 3 on linux-loong64-3a5000

@gopherbot
Copy link

Change https://go.dev/cl/408434 mentions this issue: dashboard: add privateGoProxy setting for linux-loong64-3a5000

gopherbot pushed a commit to golang/build that referenced this issue May 25, 2022
Because these builders are behind the firewall, they may not access to
proxy.golang.org, but it has a private Go module proxy.

For golang/go#46229.

Change-Id: Ib125cdaafca465f85531750cb9f5eb36d54f02de
Reviewed-on: https://go-review.googlesource.com/c/build/+/408434
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
gopherbot pushed a commit to golang/build that referenced this issue May 26, 2022
For golang/go#46229

Change-Id: Ie2896d28fc6c5e3f7e0544daccfd0c8e6e65bcf8
Reviewed-on: https://go-review.googlesource.com/c/build/+/407935
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
@gopherbot
Copy link

Change https://go.dev/cl/410816 mentions this issue: doc/go1.19: document loong64 port

gopherbot pushed a commit that referenced this issue Jun 7, 2022
Updates #46229
For #51400

Change-Id: Iedd5d3c4cd656b59ba2e1fe813851830849a8614
Reviewed-on: https://go-review.googlesource.com/c/go/+/410816
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Austin Clements <austin@google.com>
@XiaodongLoong XiaodongLoong modified the milestones: Backlog, Go1.19 Jun 13, 2022
@XiaodongLoong XiaodongLoong added the arch-loong64 Issues solely affecting the loongson architecture. label Jun 13, 2022
@gopherbot
Copy link

Change https://go.dev/cl/412236 mentions this issue: go/analysis: enable test for loong64

@ianlancetaylor
Copy link
Contributor

Thanks all. The port is complete. Remaining problems can be handled as specific issues.

@gopherbot
Copy link

Change https://go.dev/cl/417715 mentions this issue: doc/go1.19: improve the loong64 release notes

gopherbot pushed a commit that referenced this issue Jul 28, 2022
Link to the LoongArch documentations site, mention the ABI variant
supported, and add a note about the unfortunate old-world/new-world split
situation that users must be aware of.

Updates #46229
For #51400

Change-Id: I6789f509263a0dbf113481148665e7951aa6a989
Reviewed-on: https://go-review.googlesource.com/c/go/+/417715
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: abner chenc <chenguoqi@loongson.cn>
jproberts pushed a commit to jproberts/go that referenced this issue Aug 10, 2022
Link to the LoongArch documentations site, mention the ABI variant
supported, and add a note about the unfortunate old-world/new-world split
situation that users must be aware of.

Updates golang#46229
For golang#51400

Change-Id: I6789f509263a0dbf113481148665e7951aa6a989
Reviewed-on: https://go-review.googlesource.com/c/go/+/417715
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: abner chenc <chenguoqi@loongson.cn>
@gopherbot
Copy link

Change https://go.dev/cl/453457 mentions this issue: dashboard: update host-linux-loong64-3a5000 owner, ExpectNum, bootstrap

gopherbot pushed a commit to golang/build that referenced this issue Nov 30, 2022
For golang/go#46229

Change-Id: I817d6af1735fb5ca659d4537d401e93ce8e08df0
Reviewed-on: https://go-review.googlesource.com/c/build/+/453457
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Auto-Submit: Carlos Amedee <carlos@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Carlos Amedee <carlos@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: xiaodong liu <teaofmoli@gmail.com>
@wzyxdwll
Copy link

wzyxdwll commented Jun 27, 2023

Hi community,

I am from Loongson company (R & D CPU), and we have developed a new RISC CPU instruction architecture named LoongArch.

We have successfully ported linux/loongarch64 in Go version 1.15.6, and want to submit some patches to the Go community to support this port.

To support linux/loongarch64 port, we have a plan: (1) provide a builder machine (Loongson 3A5000/2.2GHz,debian-buster / 4.19 linux-kernel) remotely. (2) submit the patches in August (after Go 1.17 release). (3) complete the submission and review of all patches by November and be stable state. (4) maintain linux/loongarch64 port and builder machine for a long time.

i use window x64, set GOOS=linux, set GOARCH=loong64 and the go version is 1.20.4,this release can support loongarch native built
but, i used the cross-compiled binary file to run on loongarch's linux, and a segment error occurred
why? can you tell me how fix this problem

@xen0n
Copy link
Member

xen0n commented Jun 27, 2023

i use window x64, set GOOS=linux, set GOARCH=loong64 and the go version is 1.20.4,this release can support loongarch native built but, i used the cross-compiled binary file to run on loongarch's linux, and a segment error occurred why? can you tell me how fix this problem

This issue is for tracking the initial upstreaming of the linux/loong64 port, which was already done a while ago. Please create a new issue for reporting your findings (and provide more details so we can reproduce at all).

hubot pushed a commit to luci/luci-py that referenced this issue Mar 12, 2024
In Golang, the GOARCH defined for loongarch64 is loong64.

Related links:
	golang/go#46229
	golang/go#65398

Change-Id: Idd99c006e8c069f5936654bfafcccf4168f51876
Reviewed-on: https://chromium-review.googlesource.com/c/infra/luci/luci-py/+/5334945
Reviewed-by: Chan Li <chanli@chromium.org>
Commit-Queue: Vadim Shtayura <vadimsh@chromium.org>
Reviewed-by: Vadim Shtayura <vadimsh@chromium.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
arch-loong64 Issues solely affecting the loongson architecture. Proposal Proposal-Accepted Proposal-FinalCommentPeriod
Projects
Development

No branches or pull requests