Open HeliC829 opened 1 year ago
cc @cherrymui
See my comment over at https://github.com/golang/go/issues/59415#issuecomment-1540256806
@randall77 I think that your comment has been addressed: the proposal here is permitting setting GOMIPS64
to direct the compiler to generate a few special purpose instructions.
@HeliC829 The GOMIPS64
variable already exists, of course. I think that you are suggesting that we permit a comma-separate list of options in GOMIPS64
. The options can be
hardfloat
(default) or softfloat
r1
(default), r2
, r3
, r5
, r6
I added r1
because there has to be a way to specify the default. I added the others because compilers support them. I don't know what happened to r4
.
Do you have any reference to what the different ISA levels mean? I couldn't find one.
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 : https://s3-eu-west-1.amazonaws.com/downloads-mips/documents/MD00083-2B-MIPS64INT-AFP-06.01.pdf
Golang currently support MIPS III
on MIPS64, to be notice, MIPS III
is different from MIPS R1
. So we could consider 3
as the default level,
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 3
as the default level while also permitting r1
. Can we come up with a list of strings that makes sense today and also for the future?
OK, so let us use roman numerals iii
mean default level MIPS III
? And the value related to isa level are as follows:
iii
: MIPS III
(default, also current MIPS64 isa level)
r1
:MIPS R1
r2
:MIPS R2
r5
:MIPS R5
r6
:MIPS R6
From the doc linked above:
It sounds like GOMIPS64 is a comma-separated list of choices: hardfloat, softfloat, iii, r1, r2, r5, r6. Probably we should define them all: iii, iv, v, r1, r2, r3, r5, r6. We may not use them today but they'll be defined.
Do I have that right?
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
It sounds like GOMIPS64 is a comma-separated list of choices: hardfloat, softfloat, iii, r1, r2, r5, r6.
Right.
Probably we should define them all: iii, iv, v, r1, r2, r3, r5, r6. We may not use them today but they'll be defined.
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. — rsc for the proposal review group
Based on the discussion above, this proposal seems like a likely accept.
Excited news! Thanks for your review.
GOMIPS32=iii and GOMIPS32=iv and GOMIPS32=v
Did you mean GOMIPS64?
they exist(ed) and it's easy to include them, so we might as well recognize the full set.
Let me summarize:
ISA level | GOMIPS32 | GOMIPS64 |
---|---|---|
i | defined, ? | N/A |
ii | defined, ? | N/A |
iii | N/A | valid, implemented (current default) |
iv | N/A | valid, equivalent to iii |
v | N/A | valid, equivalent to iii |
r1 | valid, implemented (current default) | valid, ?[^1] |
r2 | valid, to be implemented | valid, to be implemented |
r3 | valid, equivalent to r2 |
valid, equivalent to r2 |
r4[^2] | N/A | N/A |
r5 | valid, to be implemented | valid, to be implemented |
r6 | valid, to be implemented | valid, to be implemented |
[^1]: I consider we can make GOMIPS64=r1
equivalent to GOMIPS64=iii
for the time being, or separate r1-compatible optimizations from the GOMIPS64=r2
patchset if it is not too complex.
[^2]: Does not exist.
Change https://go.dev/cl/493816 mentions this issue: cmd/internal/obj/mips: add REBH/REBHV/REHVV instructions
Change https://go.dev/cl/485595 mentions this issue: math/bits: optimize BitLens64/32 on mips64x
Excited news! Thanks for your review.
GOMIPS32=iii and GOMIPS32=iv and GOMIPS32=v
Did you mean GOMIPS64?
they exist(ed) and it's easy to include them, so we might as well recognize the full set.
Let me summarize:
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. 🎉 This issue now tracks the work of implementing the proposal. — rsc for the proposal review group
Change https://go.dev/cl/508095 mentions this issue: internal/buildcfg: add support for accepting different MIPS ISA level on mips64
Change https://go.dev/cl/515475 mentions this issue: cmd/internal/obj/mips: add SEB/SEH instructions
Change https://go.dev/cl/578175 mentions this issue: cmd/go: add GOMIPS32, GOMIPS64 ISA levels
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.
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.
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.
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):
24f83ed4e29495d5b8b6375aeaa2d34d14629c7d 83c4e533bcf71d86437a5aa9ffc9b5373208628c 68fea523fda227ca5fe7a1eadb7542be4b0a840c 918d4d46cd17192a81a6aced57d09827560ad9f0
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.
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):
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 src/internal/cpu/
. Tested again and everything is fine.
Sorry for the noise!
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..