Re: Softfloat on i386

чт, 1 янв. 2026 г., 04:23 Taylor R Campbell <riastradh%netbsd.org@localhost>:

> Date: Wed, 31 Dec 2025 18:10:42 +0000 (UTC)
> From: Benny Siegert <bsiegert%netbsd.org@localhost>
>
> In PR 59871, the submitter is asking for all Go on i386 to be switched to
> softfloat, so that the resulting binaries run in a 486.
>
> Is that a reasonable request? Are pkgsrc binary packages supposed to run
> on 486 processors?

In principle, that is a reasonable request: any optimizations that
rely on newer CPU features should have runtime conditionals to check
for the CPU features before using them, and should have a fallback
that does not rely on them.

For `NetBSD/i386' (which for a long time has really been i486DX -- the
x87 floating-point unit has been mandatory for over a decade, though I
did hear of someone working to revive optional x87 support for i386 or
i486SX CPUs in the last year or so with kernel softfloat), that means
x87 floating-point can be assumed but MMX/SSE/SSE2 requires runtime
conditionals.

In practice, well... This only affects hardware that is >>20 years
old, and there's likely to be a hefty performance impact on anyone
using <20-year-old 32-bit CPUs (of which there are plenty, or 64-bit
CPUs in a 32-bit userland).

I use 32bit Slackware 15.0 against x86-64 kernel.

There I compiled Go from slackbuilds.org but it seems my build defaulted to sse2:

guest@slax:~$ qemu-i386 -cpu pentium /usr/lib/go1.22.7/go/bin/go version

qemu: uncaught target signal 4 (Illegal instruction) - core dumped

��

guest@slax:~$ qemu-i386 -cpu pentium2 /usr/lib/go1.22.7/go/bin/go version

qemu: uncaught target signal 4 (Illegal instruction) - core dumped

��

guest@slax:~$ qemu-i386 -cpu pentium3 /usr/lib/go1.22.7/go/bin/go version

qemu: uncaught target signal 4 (Illegal instruction) - core dumped

��

guest@slax:~$ qemu-i386 -cpu pentium4 /usr/lib/go1.22.7/go/bin/go version

qemu-i386: unable to find CPU model 'pentium4'

guest@slax:~$ qemu-i386 -cpu core2duo /usr/lib/go1.22.7/go/bin/go version

go version go1.22.7 linux/386

====

I only needed it for Docker

I had this impression that Go build itself with previous version of Go (like Rust), so building whole chain if you skipped update can be long mission. But may be this was changed in new versions of Go, or only Slackbuild worked this way.

How do we weigh these against each other?

Maybe it's not a big performance impact because the Go world doesn't
tend to be heavy on numerical analysis, so maybe softfloat by default
for i386 is fine. But we should measure the impact, anyway.

> Or should it be an option?

I think that would be a good start. Likely also useful for other
architectures like mips, if they were ever to happen, where a lot more
CPUs were shipped in the real world without FPUs, like the erlite3.