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. :)
From an outside POV, Linux supports quite unreasonably old hardware, so it's always weird and surprising when someone decides that "now it's TOO unreasonable to keep supporting it".
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.
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.
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.
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
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.
I recently encountered this when developing for atmel attiny13a, that has 1KB memory for code. I found that my code somehow cannot fit. Then found that just one line takes around 100 bytes.
Insane!
After some experiments, I remembered university course and was able to understand what is going on.
When using float types or operations, fpu emulation is used, which takes huge amount of memory for anything.
I think atmel is using gcc, but not sure if you emulation is part of gcc or atmel libraries.
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.
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.
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.
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...
“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.
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.
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.
"Initial reviews of the i486SX chip were generally poor among technology publications and the buying public, who deemed it an example of crippleware." [1]
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. :)
> 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/
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@...
From an outside POV, Linux supports quite unreasonably old hardware, so it's always weird and surprising when someone decides that "now it's TOO unreasonable to keep supporting it".
It often shows up when someone needs to touch an area of code, where archaic compatibility makes everyone’s life harder.
Good thing this has nothing to do with NetBSD.
Not only the 486SX but a lot of alternative x86 SoCs aimed at embedded systems have no FPU, including the original Vortex86.
I wonder if this means we will soon be able to run Netbsd-10.1 (and above) on MiSTer with ao486 core.
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.
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
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
That .jpg in the readme file loaded from right to left. What is this sorcery?
Pretty sure it's orientation in the jpeg itself
Apparently¹ :
I'm also impressed. :-D1: https://github.com/mezantrop/i486SX_soft_FPU/blob/main/READM...
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.
I am also just noticing the laptop display seems to be held together with K'nex... truly a hacker setup.
I believe at least some of it is LEGO Technic
https://x.com/Mezzzantrop/status/1880490334452609425 If you are interested, that's how the gear looks like ;)
I tried it under the Misterfpga ao486 core and it failed, not finding a partition to boot from. :(
So you just consoomed something. Thanks for the contribution
These used to be very common before Pentium processors. Many (most?) compiler tool chains included a software FPU emulator.
Very cool project!
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.
Could a table help there?
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.
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
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.
I recently encountered this when developing for atmel attiny13a, that has 1KB memory for code. I found that my code somehow cannot fit. Then found that just one line takes around 100 bytes. Insane!
After some experiments, I remembered university course and was able to understand what is going on.
When using float types or operations, fpu emulation is used, which takes huge amount of memory for anything.
I think atmel is using gcc, but not sure if you emulation is part of gcc or atmel libraries.
finally something really useful, I wish you creative success, you are doing the right thing
What are some examples of an OS needing to do floating point numbers calculations?
This is super cool!
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.
The full license for Linux prior to 0.12 was:
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.I don't think the BSD license is compatible with "you may not distribute this for a fee"
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.
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...
“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.
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.
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.
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.
[flagged]
It's not emulating a crippled chip, it runs on the i486SX (which has no FPU, by artificial limitation or not), and emulates an x87 FPU.
> It's not emulating a crippled chip
"Initial reviews of the i486SX chip were generally poor among technology publications and the buying public, who deemed it an example of crippleware." [1]
[1] https://en.wikipedia.org/wiki/486sx
EDIT: I get your point but this is what OP was referring to