all: port to linux/loong64 · Issue #46229 · golang/go · GitHub

dmitshur commented on May 18

CC @golang/release.

mengzhuo commented on May 19

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

ianlancetaylor commented on May 19

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 commented on May 19

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 commented on May 19

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 commented on May 20 •

@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 commented on May 20

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 commented on May 20

@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 commented on May 20

@XiaodongLoong thanks for clarifying

rsc commented on May 26

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 commented on May 27

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 commented on May 27

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

XiaodongLoong commented on May 31 •

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 commented on May 31

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 commented on Jun 2

Thanks @XiaodongLoong. We will wait for your response.

XiaodongLoong commented on Jun 5

@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 commented on Jun 5

happy with GOARCH=loong64

dongzerun commented on Jun 5

happy with GOARCH=loong64 too

bigwhite commented on Jun 5

prefer GOARCH=loong64

xen0n commented on Jun 5 •

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=LoongArch64 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 commented on Jun 6

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 commented on Jun 6

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.

Change https://golang.org/cl/342303 mentions this issue: copyright: add Loongson into AUTHORS

Change https://golang.org/cl/342304 mentions this issue: cmd/asm/internal: port to linux/loong64

Change https://golang.org/cl/342305 mentions this issue: cmd/cgo: port to linux/loong64

Change https://golang.org/cl/342306 mentions this issue: cmd/compile/internal: port to linux/loong64

Change https://golang.org/cl/342307 mentions this issue: cmd/dist: port to linux/loong64

Change https://golang.org/cl/342308 mentions this issue: cmd/go/internal: port to linux/loong64

Change https://golang.org/cl/342309 mentions this issue: cmd/internal/obj/loong64: port to linux/loong64

Change https://golang.org/cl/342310 mentions this issue: cmd/internal/obj: port to linux/loong64

Change https://golang.org/cl/342311 mentions this issue: cmd/internal/objabi: port to linux/loong64

Change https://golang.org/cl/342312 mentions this issue: cmd/internal/sys: port to linux/loong64

Change https://golang.org/cl/342313 mentions this issue: cmd/link/internal/loong64: port to linux/loong64

Change https://golang.org/cl/342314 mentions this issue: cmd/link/internal: port to linux/loong64

Change https://golang.org/cl/342315 mentions this issue: cmd/link: port to linux/loong64

Change https://golang.org/cl/342316 mentions this issue: internal/bytealg: port to linux/loong64

Change https://golang.org/cl/342317 mentions this issue: syscall: port to linux/loong64

Change https://golang.org/cl/342318 mentions this issue: internal: port to linux/loong64

Change https://golang.org/cl/342319 mentions this issue: runtime/cgo: port to linux/loong64

Change https://golang.org/cl/342320 mentions this issue: runtime/internal: port to linux/loong64

Change https://golang.org/cl/342322 mentions this issue: runtime: port to linux/loong64

Change https://golang.org/cl/342321 mentions this issue: cmd/vendor/golang.org/x: port to linux/loong64

Change https://golang.org/cl/342323 mentions this issue: cmd/nm, cmd/objdump, cmd/pprof: port to linux/loong64

Change https://golang.org/cl/342324 mentions this issue: debug, go, math, os, reflect, vendor: port to linux/loong64

Change https://golang.org/cl/342325 mentions this issue: misc, test: port to linux/loong64

xen0n commented 2 days ago

@XiaodongLoong What's these CLs about? I think we've communicated privately about the cooperation details as to who does what component, and I've already put out an initial revision of cmd/internal/obj and assembler port. And now a half-heartedly done MIPS-like port is submitted, neglecting all the previous work we did, and is of inferior quality?

XiaodongLoong commented yesterday

Per the request #46229 (comment), we have rebased from go1.15.6 to master branch and submitted patches to gerrit.
Unfortunately, a few test cases executed by all.bash can not pass, but we will continue to fix that.
We look forward to see your code review comments.

Thanks!

xen0n commented yesterday •

Per the request #46229 (comment), we have rebased from go1.15.6 to master branch and submitted patches to gerrit.
Unfortunately, a few test cases executed by all.bash can not pass, but we will continue to fix that.
We look forward to see your code review comments.

Thanks!

tl;dr: I've already reviewed the code, and the conclusion was that a rewrite is needed to meet upstream requirements, but you didn't listen and posted the CLs nevertheless. I strongly object to basing the whole port on the original MIPS code, and carrying MIPS-isms around (like the assembly mnemonics and so on), so I won't comment on the CLs individually.

We communicated privately about the expected quality standards, and I think we all agreed that a MIPS-based port is not acceptable; so I put forward a proposal that I implement the assembler/linker side. After getting the cmd/internal/obj interface reviewed and merged, the SSA and runtime work can then begin on Loongson's side. You and your leader expressed concern about "punctuality" issues, but @mengzhuo and I both think it's impossible to sneak loong64 into go1.18 this cycle; but after voicing our opinions, no replies from Loongson side were ever heard. I think there's something wrong with the cooperation mechanism; maybe you should review my earlier CLs too, to push things forward responsibly?

mengzhuo commented yesterday

@XiaodongLoong I think you might want to check the Porting Policy instead of submitting those CLs without testes and reviews.

All CLs necessary to run all.bash successfully must have been sent for review. Typically this will be a handful of CLs split by the part of the tree they change.
Once those conditions are satisfied, the Go team can accept the port and begin to merge the CLs. Once the CLs are all submitted, all.bash must pass, so that the builder reports "ok" in the dashboard.

p.s. Is any qualified developer want to maintain this port? @xen0n is it ok for you?

xen0n commented yesterday

@XiaodongLoong I think you might want to check the Porting Policy instead of submitting those CLs without testes and reviews.

All CLs necessary to run all.bash successfully must have been sent for review. Typically this will be a handful of CLs split by the part of the tree they change.
Once those conditions are satisfied, the Go team can accept the port and begin to merge the CLs. Once the CLs are all submitted, all.bash must pass, so that the builder reports "ok" in the dashboard.

p.s. Is any qualified developer want to maintain this port? @xen0n is it ok for you?

I think if it's my code that eventually gets merged, then I should take part in maintaining it, obviously. Currently no substantial loong64 code is in, so I'm holding up my CL for component ownership. Let's finish the code first.

XiaodongLoong commented 16 hours ago •

@mengzhuo Thank you for your reminding. We will obey the policies of the community, and continue to complete the rest of work.

@xen0n
(1)We just discussed the possibility of refactoring, but we did not reach a unified consensus.
(2)There is a precedent for the new port based on the existing port, such as mips based on ppc64.
(3)We have done a lot of work on MIPS. For example, we support buildmode=c-shared on linux/mips64le. So we chosed to develop LoongArch based on MIPS naturally.
(4)The patches is a response to the comment(#46229 (comment)). If it is necessary to refactor code in the future, you are welcome to contribute code.

Thanks!

xen0n commented 14 hours ago •

@xenon

You just misspelled my name; my ID has the number 0, not upper-case O.

(1)We just discussed the possibility of refactoring, but we did not reach a unified consensus.

And I thought silence is not exactly the way civilized people express their disagreement?

(2)There is a precedent for the new port based on the existing port, such as mips based on ppc64.

These are ports from the old times; at the time mips was ported, for example, the coding style and conventions are still considered current at that time. That doesn't automatically make the decision to base a new port on these old-style converted-from-C code valid IMHO.

(3)We have done a lot of work on MIPS. For example, we support buildmode=c-shared on linux/mips64le. So we chosed to develop LoongArch based on MIPS naturally.

But LoongArch is indigenously developed and unrelated to MIPS, at least from publicly available material that I have permission to look at; when looking from a userland perspective it's more similar to RISC-V instead (except the FCC thing, that certainly looks MIPS-y). To abandon all the MIPS legacy we clearly need to start from something new, instead of building on the previous pile of code. What's more, why build all things on top of MIPS when you're actually a brand-new unrelated arch?

(4)The patches is a response to the comment(#46229 (comment)). If it is necessary to refactor code in the future, you are welcome to contribute code.

First of all, it's of course good to keep your own promises, that builds trust. However, I take the Go team's acceptance of the proposal as a general clearance for accepting the loong64 port, and not about recognizing the roadmap you outlined as valid and actionable. And the requirement about coding standards should be considered implicit; in other words, you can't throw out this kind of code and hope to get it into acceptable shape in a mere 3 months.

Secondly, as for the contributions, I've already submitted my CLs such as CL 339010 and the whole series earlier, and I posted everything in the private communication groupchat before actually sending the series. I got no review from your side; @mengzhuo was always quick though. Disagreement about my approach is okay, but I heard no response; then you posted all these CLs per your agenda. And I always reviewed these as soon as I had time, and I still think copying MIPS is not acceptable, so we really need to get together and figure out how to get your things done, both quickly and on a fresh starting point. I already have experience upstreaming to various projects including Go, so I hope my approach would help and enable you to finish your objective sooner.

I look forward to your review and comments, and thank you for your kindness to communicate with us in the first place.

Thanks!