all: port to linux/loong64

[XiaodongLoong]

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]

CC @rsc @rsto @ianlancetaylor

[dmitshur]

CC @golang/release.

[mengzhuo]

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

[ianlancetaylor]

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]

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]

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

[XiaodongLoong]

@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]

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]

@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]

@XiaodongLoong thanks for clarifying

[XiaodongLoong]

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

[rsc]

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]

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]

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

[XiaodongLoong]

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]

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]

Thanks @XiaodongLoong. We will wait for your response.

[XiaodongLoong]

@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]

happy with GOARCH=loong64

[dongzerun]

happy with GOARCH=loong64 too

[bigwhite]

prefer GOARCH=loong64

[xen0n]

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]

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]

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]

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

[gopherbot]

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

[gopherbot]

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

[ianlancetaylor]

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

[gopherbot]

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

[gopherbot]

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

[wzyxdwll]

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]

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