cmd/go: add GOMIPS32, GOMIPS64 ISA levels (iii, r1, r2, r5, r6) #60072
Comments
|
cc @cherrymui |
|
See my comment over at #59415 (comment) |
|
@randall77 I think that your comment has been addressed: the proposal here is permitting setting @HeliC829 The
I added Do you have any reference to what the different ISA levels mean? I couldn't find one. |
Here is MIPS ISA level ref, at Page 24 of 148 : Golang currently support MIPS To resolve there is letter in ISA level, i think we can use the enum mips_isa level defined in gcc in rules. |
|
I know that the situation is very confusing, but it doesn't seem ideal to treat |
|
OK, so let us use roman numerals
|
|
From the doc linked above: 
It sounds like GOMIPS64 is a comma-separated list of choices: hardfloat, softfloat, iii, r1, r2, r5, r6. Do I have that right? |
|
This proposal has been added to the active column of the proposals project |
rsc
changed the title
Right.
Just FYI: there is no MIPS IV hardware running Linux distribution in practice and even no MIPS V hardware implementation. Besides, in user space, the difference between III, IV and V is tiny. R3 is a significant release but there are only privileged instructions added and no visible user space change compared to R2. Thus, as a minimum requirement, we consider that only defining iii, r1, r2, r5 and r6 should be enough. It is okay to define other ISA levels as reserved, of course, if there is such a demand. |
|
In practice since we don't emit code that cares about the difference, GOMIPS32=iii and GOMIPS32=iv and GOMIPS32=v will all mean the same thing, but they exist(ed) and it's easy to include them, so we might as well recognize the full set. |
|
Based on the discussion above, this proposal seems like a likely accept. |
Excited news! Thanks for your review.
Did you mean GOMIPS64?
Let me summarize:
Footnotes |
|
Change https://go.dev/cl/493816 mentions this issue: |
|
Change https://go.dev/cl/485595 mentions this issue: |
It‘s such a good summary. Besides, each newer ISA level is the superset of previous version except for R6 (R6 removed and adjusted some outdated instructions due to the changes in microarchitecture desgin). |
|
No change in consensus, so accepted. 🎉 |
|
Change https://go.dev/cl/508095 mentions this issue: |
HeliC829
changed the title
Add support for WSBH/DSBH/DSHD instructions, which are introduced in mips{32,64}r2.
WSBH reverse bytes within halfwords for 32-bit word, DSBH reverse bytes within halfwords for 64-bit doubleword, and DSHD reverse halfwords within doublewords. These instructions can be used to optimize byte swaps.
Ref: The MIPS64 Instruction Set, Revision 5.04: https://s3-eu-west-1.amazonaws.com/downloads-mips/documents/MD00087-2B-MIPS64BIS-AFP-05.04.pdf
Updates #60072
Change-Id: I31c043150fe8ac03027f413ef4cb2f3e435775e1
Reviewed-on: https://go-review.googlesource.com/c/go/+/493816
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Joel Sing <joel@sing.id.au>
|
Change https://go.dev/cl/515475 mentions this issue: |
Add support for SEB/SEH instructions, which are introduced in mips32r2. SEB/SEH can be used to sign-extend byte/halfword in registers directly without passing through memory. Ref: The MIPS32 Instruction Set, Revision 5.04: https://s3-eu-west-1.amazonaws.com/downloads-mips/documents/MD00086-2B-MIPS32BIS-AFP-05.04.pdf Updates #60072 Change-Id: I33175ae9d943ead5983ac004bd2a158039046d65 Reviewed-on: https://go-review.googlesource.com/c/go/+/515475 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Run-TryBot: Joel Sing <joel@sing.id.au>
For GOARCH=mips the Go compiler will use the newer MIPS32-r1 ISA, whereas for GOARCH=mips64 it will use the MIPS-III ISA, which is the highest N64 supports. See golang#60072
|
@cherrymui Hi, PTAL on CL 508095, thanks. |
|
Change https://go.dev/cl/578175 mentions this issue: |
This CL does not introduced any instruction after MIPS III at now. It should still behave identically to MIPS III. Updates golang#60072
|
Is there any progress on the implementation of this proposal? I'm in the process of contributing ChaCha20 and Poly1305 assembly implementations for MIPSLE to x/crypto. For ChaCha20 it would be great to use ROTR for Mips32r2 and newer. |
This CL does not introduced any instruction after MIPS III at now. It should still behave identically to MIPS III. Updates golang#60072
Unfortunately, I'm still waiting for Golang to accept my CL about adding ISA level in GOMIPS{,64} environment variable. After this, I will submit more CLs about implementing the new instructions in mips{32,64}r1, mips{32,64}r2. In the meantime, I have created a fork branch based on the golang release branch, with newer mips instructions support. (implement for mips32 will be added soon). |
|
Thanks for your status update. I'm going to link your CL from mine, that is going to add ChaCha20 and Poly1305 assembly implementations. |
This CL does not introduced any instruction after MIPS III at now. It should still behave identically to MIPS III. Updates golang#60072
|
I'm working on a mips64 target with ISA level MIPS-III. The current compiler doesn't emit valid MIPS-III code anymore. At least the following the commits must be reverted to get back to MIPS-III level (there are probably more): 24f83ed It would be greatly appreciated if MIPS-III can still be supported, or a CL accepted which adds that, once ISA level can be selected via the GOMIPS. |
For mips64, the current compiler won't emit code higher than MIPS-III. The ssa front end won't emit code higher than MIPS-III for now. Those commits mentioned above are used for ssa backend (aka assembler). It won't emit code directly. Even if this commit used MIPS MSA instructions, the runtime will detect which instructions should be executed only if MSA is available. I don't know what happened on your mips64 target, can you provide more information or logs? |
|
It was my fault. I'm running on a custom OS and didn't initialize CPU correctly in Sorry for the noise! |
This should widen compatibility a bit, so that older CPUs can also execute programs built by TinyGo. The performance may be lower, if that's an issue we can look into implementing the proposal here: golang/go#60072 This still wouldn't make programs usable on MIPS II CPUs, I suppose we can lower compatiblity down to that CPU if needed. I tried setting the -cpu flag in the QEMU command line to be able to test this, but it looks like there are no QEMU CPU models that are mips32r1 and have a FPU. So it's difficult to test this.
This should widen compatibility a bit, so that older CPUs can also execute programs built by TinyGo. The performance may be lower, if that's an issue we can look into implementing the proposal here: golang/go#60072 This still wouldn't make programs usable on MIPS II CPUs, I suppose we can lower compatiblity down to that CPU if needed. I tried setting the -cpu flag in the QEMU command line to be able to test this, but it looks like there are no QEMU CPU models that are mips32r1 and have a FPU. So it's difficult to test this.
Currently GOMIPS64 accepts hardfloat(as default) and softfloat.
Golang currently support MIPS III or higher. I had submitted two CLs and they take little performance improvement to MIPS64. CL 485635 CL 485595. But those instructions only available after r1 but not MIPS III.
So if we want to get more performance improvement on mips64, we should support more isa level.
We wish that GOMIPS can also accept
r2/r5.I tried introduce some instructions from MIPS R2. The following data shows the test results and performance improvement if we can support newer isa level on mips64x..
The text was updated successfully, but these errors were encountered: