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

[b-]

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

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

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

[martisch]

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]

/cc @randall77 @griesemer

[tbodt]

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

[martisch]

ish-app/ish#57 has been closed by ish-app supporting MOVQ now:
ish-app/ish@e898efe

Can this issue be closed?

[gopherbot]

Timed out in state WaitingForInfo. Closing.

(I am just a bot, though. Please speak up if this is a mistake or you have the requested information.)