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

cmd/compile: add support for compiling without the MMX requirement on GOARCH=386 #37056

Open
b- opened this issue Feb 5, 2020 · 5 comments
Open
Milestone

Comments

@b-
Copy link

@b- b- commented Feb 5, 2020

What version of Go are you using (go version)?

$ go version
This program can only be run on processors with MMX support.

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

go env Output and architecture information
$ go env
This software can only be run on processors with MMX support.
I am using https://github.com/tbodt/ish which emulates “more of a i486. No MMX support.”

What did you do?

I first discovered this as I attempted to install Keybase on https://github.com/tbodt/ish. However, it’s not actually a Keybase issue but rather a golang/iSH issue, as iSH does not implement the Pentium MMX Extensions, when golang compiled with $GO386=387 actually requires Pentium MMX extensions. ish-app/ish#57

ish-app/ish#618

@b-
Copy link
Author

@b- b- commented Feb 5, 2020

I think it might be better for https://github.com/tbodt/ish to implement MMX support in the CPU emulator, but in the meantime this would certainly be a welcome feature.

@b- b- changed the title [Request] Add support for software FPU on 386 arch [Request] Add support for compiling without the MMX requirement on 386 arch Feb 5, 2020
@b-
Copy link
Author

@b- b- commented Feb 5, 2020

Come to think of it, the Intel Quark does not have MMX support either, so this would allow support for golang on that.

@odeke-em odeke-em changed the title [Request] Add support for compiling without the MMX requirement on 386 arch cmd/compile: add support for compiling without the MMX requirement on GOARCH=386 Feb 5, 2020
@martisch
Copy link
Member

@martisch martisch commented Feb 6, 2020

As far as I remember the fundamental reason why MMX is needed is that otherwise there is no fast/easy way to atomically write 64bit with non-mmx instructions that are part of x86.

One can go through floating point load and stores but that requires making sure the floating point control has 64bit mantissas set. Im not sure go enforces/requires that.

One can use lock cmpxchg8b but thats not guaranteed to exist as part of the instruction set so one would need to check for that instead of mmx. It is also has catastrophic performance implications being slower by x100 in some cases.

In the era of P5 and P6 pentiums also the guarantees changed for aligned/unaligned 64bit load/store atomicity guarantees. P5 only supported atomicity on naturally aligned (64bit for 64bit int) load/stores. That however may not be an issue since I think all callers are required to use 64bit alignment already for runtime atomic.

More practical problems:
How would we test we dont regress introducing a non mmx instruction somewhere? We would need SMP builders that run in non mmx mode to catch regressions. Maybe QEMU can do this but it will be slow.

If its not implemented as an option it will likely slow down other x86 systems that have MMX.

Is the maintenance burden supporting an extra option (running builders, code maintenance) worth the potential usage for the use case. Maybe gcc-go, tinygo are already better since they can also optimize for the specific cpu?

@cagedmantis cagedmantis added this to the Backlog milestone Feb 7, 2020
@cagedmantis
Copy link
Contributor

@cagedmantis cagedmantis commented Feb 7, 2020

@tbodt
Copy link

@tbodt tbodt commented Apr 18, 2020

Is there a list of the MMX instructions that go uses? It's probably a much better idea to just implement those in iSH.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.