Re: Softfloat on i386

[David Holland <dholland-pkgtech%netbsd.org@localhost>]

On Wed, Dec 31, 2025 at 07:15:48PM -0500, Greg Troxel wrote:
 > > The problem is that go is a compiler and it apparently only supports
 > > codegen for either (a) sse2 and newer or (b) softfloat. This means
 > > there's a range of non-486SX (and non-486) machines where the only
 > > working option is softfloat.
 > 
 > I'd call that a bug in go.

So would I, but it's also a reasonable support choice if you don't
have a retrocomputing or otherwise niche audience. x86 cpus without
sse2 are, mostly, more than 20 years old now.

Obviously, anyone who wants to get involved with this particular
windmill is welcome to try to implement older x86 FPU support and try
to get it merged upstream :-)

 > I see multiple cases:
 > 
 >   Machines that haven't been converted over to amd64 even though they
 >   could be.  I have 1 of these, originally installed in the mid-2000s,
 >   still not amd64 for reasons I won't explain but are valid if you
 >   understood the details, and I know of another such system.

Right, I still have one as well :-|  But it builds its own packages.

 >   Semi-restricted CPUs for embedded/SBC.  I have an apu2 which has
 >     cpu0: AMD GX-412TC SOC                               , id 0x730f01
 >   which runs amd64 but my previous one was a 586-ish geode.

That's the exception to where I wrote "mostly" above. Rad-hardened
devices for aerospace use in particular lag a long way behind. I don't
know what the current state of things is but I wouldn't be surprised
to see 586-ish and even 486-ish processors still floating around.

OTOH, most people noodling with such devices also have build machines,
and building your own i386 packages in a chroot on an amd64 build
machine is not complicated. (Unlike many other combinations.)

 >   Machines that were modern in 2003 but don't quite run amd64.
 > 
 >   Then there's true 486 from the 90s, which if desktoppy I sort into
 >   retrocomputing.

I'd describe both of these as retrocomputing. There's no reason to
junk a running 20-year-old x86 if you have a mission for it that fits
in its RAM. But there aren't many such missions, or so many
still-working machines, and likely the power bill justifies replacing
them anyway. :-|

So I guess the question is: which parts of this audience are we really
intending to cater to, and how much of it is pre-sse2 hardware? Or
should we be running multiple sets of (maybe smaller) builds?

(Obviously support or not support of something just in golang is not
itself a reason to rearrange the set of builds we have or the
subcategories of x86 they're intended for. But looking at that
categorization periodically to see if it's still sensible is probably
worthwhile.)

-- 
David A. Holland
dholland%netbsd.org@localhost