[HN Gopher] Show HN: I486SX_soft_FPU - Software FPU Emulator for...
___________________________________________________________________
Show HN: I486SX_soft_FPU - Software FPU Emulator for NetBSD 10 on
486SX
First Release is Here! I'm excited to announce the first release
of i486SX_soft_FPU -- a software FPU emulator for the classic Intel
486SX CPU, running on NetBSD 10! This project brings floating-
point support back to life for 486SX machines, even though modern
NetBSD versions no longer natively support processors without a
hardware FPU. If you're into retrocomputing, operating system
hacking, or just love old-school hardware, check it out! Project
page: https://github.com/mezantrop/i486SX_soft_FPU Contributions,
feedback, and testing are all very welcome! Let's keep these
vintage machines alive! #retrocomputing #NetBSD #486SX #opensource
Author : mezantrop
Score : 108 points
Date : 2025-04-27 21:04 UTC (1 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| dlachausse wrote:
| These used to be very common before Pentium processors. Many
| (most?) compiler tool chains included a software FPU emulator.
|
| Very cool project!
| actionfromafar wrote:
| I think GCC didn't have the emulating library, but the
| operating system had. (Such as Debian.) So you could compile
| and link your programs against a soft-float library. (
| Something like this https://github.com/ant6n/ieeelib )
|
| What this NetBSD project does is not exactly like that though,
| it lets programs use regular 487 float instructions, which are
| trapped by the kernel, which steps in and emulates what the
| hardware float instruction would have done.
|
| It worked very well for regular program, because most programs
| would not use float instructions to any significant degree.
|
| If you however were going to use floats a lot for long
| calculations, a soft-float library would be much faster.
| queenkjuul wrote:
| Funny enough, I've been compiling a lot of stuff for 386
| Linux lately. You can build a kernel with built in software
| floating point, at which point it doesn't matter what your
| library/compiler do. If your kernel isn't built to handle
| that, you can build glibc with floating point emulation.
|
| At least this is my impression, working with 2.2.x/2.4.x
| kernels, gcc 2.7~3.3, and glibc ~2.2
| anyfoo wrote:
| Yap. But as hinted by the comments before you, if you have
| CPUs without FPUs, you probably want to enable userspace
| (e.g. glibc) soft math support anyway, since it doesn't
| have the overhead of trapping the instructions and context
| switching into the kernel and back.
|
| The benefit of OP's solution in the kernel is that it works
| for everything out of the box, including pre-compiled
| binaries, and those that you can't rebuild for whatever
| reason to begin with.
| rasz wrote:
| Duke Nukem 3D is compiled with FPU emulation. Game engine is
| 99.9% fixed point math, only requires FPU for rarely used
| slopes (setupslopevlin_ and slopevlin_).
|
| It just so happens first room when starting the game - rooftop
| - has sloped roof vents and later walls with sloped edge. Even
| on fast FPUless 90MHz NexGen Nx586 (AMD K6 father) FPS drops
| down to 10-14fps on that roof
| https://www.youtube.com/watch?v=41O2bNG2qKA&t=234s while
| staying above 30 when facing away from slopes.
| anthk wrote:
| Could a table help there?
| rzzzt wrote:
| That .jpg in the readme file loaded from right to left. What is
| this sorcery?
| actionfromafar wrote:
| Apparently1 : <img align="right">
|
| I'm also impressed. :-D
|
| 1:
| https://github.com/mezantrop/i486SX_soft_FPU/blob/main/READM...
| accrual wrote:
| The align tag isn't related, the image will load right-to-
| left even if opened by itself in a new tab.
|
| In JPEGSnoop I see Raw Image Orientation = Landscape. Maybe
| it was taken and encoded horizontally and the image itself is
| stored in a right-to-left scan order.
| accrual wrote:
| I am also just noticing the laptop display seems to be held
| together with K'nex... truly a hacker setup.
| akadruid1 wrote:
| I believe at least some of it is LEGO Technic
| mezantrop wrote:
| https://x.com/Mezzzantrop/status/1880490334452609425 If
| you are interested, that's how the gear looks like ;)
| adzm wrote:
| Pretty sure it's orientation in the jpeg itself
| quotemstr wrote:
| Z$ identify -verbose weird-jpeg.jpg Image:
| Filename: weird-jpeg.jpg ... Orientation:
| RightTop ^^^^^^^^^^^^^^^^^^^^^^^^^^ ...
| Properties: ... unknown: iPhone 12 Pro
| queenkjuul wrote:
| This is awesome. I'm working on packaging a Linux distro for my
| 386 and 486, but I've stuck to just using very old kernels.
| LeFantome wrote:
| I am sure you are aware of this:
| https://github.com/marmolak/gray386linux
|
| It uses kernel 3.7
|
| For 486, there was a release just two months ago using kernel
| 6.13: https://github.com/marmolak/gray486linux
| queenkjuul wrote:
| I actually wasn't familiar with those, they're cool but don't
| quite fit all my goals, though could still be useful to me
| accrual wrote:
| This is super cool and I'm very glad to see such work! Does
| NetBSD natively support the 486DX CPUs which still have the FPU
| enabled?
|
| I know OpenBSD dropped support for i486 in 6.8, making 6.7 the
| last that runs natively on them (FPU or not). The support was
| lost when moving to LLVM 9 and enabling `-march=i586 on i386`.
| However, old Socket 3 boards can still run the latest version of
| OpenBSD if one drops a Pentium Overdrive in. :)
| dcassett wrote:
| > Does NetBSD natively support the 486DX CPUs which still have
| the FPU enabled?
|
| According to [1] they do
|
| "Any i486 or better CPU should work - genuine Intel or a
| compatible such as Cyrix, AMD, or NexGen."
|
| [1] https://wiki.netbsd.org/ports/i386/
| PrivacyAI wrote:
| This is super cool!
| hsnewman wrote:
| I tried it under the Misterfpga ao486 core and it failed, not
| finding a partition to boot from. :(
| natas wrote:
| I wonder if this means we will soon be able to run Netbsd-10.1
| (and above) on MiSTer with ao486 core.
| userbinator wrote:
| Not only the 486SX but a lot of alternative x86 SoCs aimed at
| embedded systems have no FPU, including the original Vortex86.
| jabl wrote:
| Just a few days ago patches were posted proposing to drop Linux
| kernel support for x86 cpus lacking a FPU:
| https://lore.kernel.org/lkml/20250425084216.3913608-1-mingo@...
| remlov wrote:
| Good thing this has nothing to do with NetBSD.
| evmar wrote:
| I noticed math_emulate.c comes from Linux (it even has a " * (C)
| 1991 Linus Torvalds" bit on it). I was wondering what the license
| on that code is. It looks like Linux adopted GPL in 1992 so maybe
| this copy predates that, but it was under some other non-BSD
| license before that.
| einr wrote:
| The full license for Linux prior to 0.12 was:
| This kernel is (C) 1991 Linus Torvalds, but all or part of it
| may be redistributed provided you do the following:
| - Full source must be available (and free), if not with the
| distribution then at least on asking for it. -
| Copyright notices must be intact. (In fact, if you distribute
| only parts of it you may have to add copyrights, as there
| aren't (C)'s in all files.) Small partial excerpts may
| be copied without bothering with copyrights.
| - You may not distibute this for a fee, not even "handling"
| costs.
|
| This is clearly written by someone who has no business writing
| software licenses ;) but does not appear to be incompatible
| with the BSD license and in fact, the code in question
| originates from 386BSD (https://github.com/386bsd/386bsd/blob/2
| .0/usr/src/kernel/mat...) and made it from there into the
| NetBSD mainline.
| nikanj wrote:
| I don't think the BSD license is compatible with "you may not
| distribute this for a fee"
| einr wrote:
| True! And if so, that license has clearly been broken many
| times by everyone selling 386BSD, NetBSD and Linux <0.12 on
| CD-ROMs etc ;)
|
| Then again -- and IANAL -- the license is worded so vaguely
| that I doubt any of it is enforcible. "You may not
| distibute this for a fee" -- what is "this"? Is it the
| entire kernel or does it apply to small excerpts of it?
| Because apparently "small partial excerpts may be copied
| without bothering with copyrights". But do you mean
| copyright _attribution_ or are you rescinding your
| copyright entirely if I only copy "small partial
| excerpts"? But what is a small partial excerpt? And so on
| and so forth...
| wkat4242 wrote:
| I think nikanj means that this is not a stipulation of
| the BSD license at all, that's why it's not compatible
| with what Linus made there.
| LeFantome wrote:
| But the Linus license has no bearing on the rest of the
| code base at all.
|
| The entire concept of "compatibility" is an artifact of
| copyleft. In the rest of the license universe, each piece
| of code is covered by its own license and it does not
| matter what licenses other code uses.
|
| This license does not apply to the rest of BSD. The BSD
| license does not apply to this code.
| LeFantome wrote:
| "this" is the code that Linus licensed as he did. Only
| that code. If you use a snippet, that snippet is governed
| by the license. The license does not magically extend to
| other code or even to any modifications that have been
| made since. This is not the GPL.
| yjftsjthsd-h wrote:
| Why not? BSD style licenses generally just impose
| constraints around liability and attribution; I can't see
| any reason why that wouldn't be compatible with a separate
| constraint on charging money. IANAL, though, so take with
| grain of salt.
| LeFantome wrote:
| The GPL has wrongly taught us to focus on "compatibility".
| Compatibility is pretty much exclusively a copyleft issue.
|
| There is no reason that you cannot use this code with this
| license in a larger BSD work. It is "compatible" in that
| sense.
|
| This specific code has additional restrictions (not
| charging). That does not add any restrictions to the rest
| of the code though.
|
| So, if you are charging, you are in violation of the
| license just for this code snippet. Linus Torvalds, the
| copyright holder, could try to enforce the license against
| you. Since he gives it away, no financial damages. Which
| means the remedy would be that you would not be able to use
| this code anymore (but could still use the rest of BSD).
|
| I do not expect Linus to pursue enforcement on this one.
|
| It would be a very difficult case to win anyway as you
| would have to prove that people were being charged
| specifically for the Linus code and not for other code
| covered by BSD (which allows charging).
|
| I would argue that this license has not even been violated,
| unless somebody has put a price tag on this specific code.
| Turboblack wrote:
| finally something really useful, I wish you creative success, you
| are doing the right thing
| bezko wrote:
| What are some examples of an OS needing to do floating point
| numbers calculations?
___________________________________________________________________
(page generated 2025-04-28 23:02 UTC)