Rendered at 03:56:01 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
rep_lodsb 1 days ago [-]
Division by zero is handled the same on x86, and also changed from "trap" to "fault" after the original 8086/8088. And despite what is often said about its variable-length instruction format, skipping over opcodes is pretty much trivial compared to VAX.
Early versions of Microsoft Flight Simulator included a handler for the divide exception, which adjusted the result to +/- "infinity" (for a 16-bit signed integer, 32767 or -32768). The rest of the code relied on this in order to work correctly, and it was more efficient to take advantage of the processor's microcode doing this check rather than coding it explicitly before every division.
So even if it doesn't make mathematical sense, being able to continue after this type of exception is a useful feature to have.
>(and if you ignore SIGSEGV, it is considered perfectly acceptable that your program spins in a SIGSEGV loop until you kill it.)
This, on the other hand, shouldn't ever be acceptable. If a fatal-by-default signal is just ignored, it should always terminate the process.
globalnode 2 days ago [-]
interesting read, makes me think kernel programming isnt that much harder than app programming, just more manuals to read and hardware to understand.
edit: not to dismiss kernel programmers, you people are awesome!
kev009 2 days ago [-]
Attention to detail is a lot more important. But the kernel is just a program.
ahoka 2 days ago [-]
It's exactly like that. :)
saidnooneever 2 days ago [-]
try it :D its a lot of fun!
globalnode 1 days ago [-]
being a bit of a masochist myself, with that user name you make a really tempting proposition
iberator 1 days ago [-]
try writing your own 512 bytes MBR sector.
It is so easy to learn x86 assembly that way, and actually understand WHY BIOS was so important.
Os development is so easy nowdays with internet forums...
DeathArrow 2 days ago [-]
I wonder if we can't do something much better than the old UNIX paradigm today.
25 years ago there was an avalanche of new operating systems and if somebody asked me at that time, I was sure we will have much better operating systems in the future using fresh ideas.
I am not saying UNIX is bad, just that I would like to see some advancements in the OS area, beside improving UNIX kernels and APIs.
cenamus 2 days ago [-]
If you haven't already, take a look at Plan 9, and maybe Rob Pikes talk "The Good, the Bad, and the Ugly: The Unix Legacy"
The lack of vertical integration in the modern stack is surprising. We’ve spent 30 years treating the UNIX paradigm as the "end of history," while burying ourselves in layers that add zero mechanical value.
I initially thought the containerization movement of the early 2010s would be the first step toward redefining the OS—a way to finally slim things down. Instead, it just became a more efficient way to pack up the same baggage. We created a "reduction" in deployment complexity, but we haven't seen a continued effort to use those tools to actually change the paradigm.
I expected vertically integrated systems to become the norm by now—where building an executable would be an experience similar to containerization, but resulting in a lean, data-centric unikernel.
Instead, we are burning CAPEX on YAML sidecars in K8s clusters and N-tier abstractions that exist solely due to the large heterogeneity of the deployments that they never should have entered in the first place. We are spending more energy on the friction between layers than on the actual business of computation.
I was hoping for a return to sanity with the DBOS [1] research, looked like an attempt to rethink systems from first principles. But it seems that effort hasn't fully kicked off in the way the industry desperately needs.
The only thing worse than spaghetti code is spaghetti services.
Ask yourself which one is easier to diagnose and debug.
sillywalk 1 days ago [-]
> 25 years ago there was an avalanche of new operating systems
Which ones? I can only think of maybe Microsoft Singularity in 2003, and hobby OS Syllable. Neither were particularly innovative - the managed code thing had been done before with Inferno, and Syllable was heavily inspired by BeOS.
kQq9oHeAz6wLLS 2 days ago [-]
The problem is if you lack backwards compatibility, you won't see people migrate to it. At best that means you need a big emulation layer; at worst your OS isn't different enough to be worth the switch.
ciupicri 2 days ago [-]
Hardware compatibility too.
snvzz 2 days ago [-]
For the state of the art, look at seL4[0], LionsOS[1] and Genode[2].
> I would like to see some advancements in the OS area, beside improving UNIX kernels and APIs
Most of the people today are afraid to build OSs so they stick to virtual machines. An OS without drivers is not an OS.
somat 2 days ago [-]
Now I am wondering how VMS handled this. Do VMS programs just get no chance to recover from arithmetic faults? That is, do whatever the VMS equivalent is to masking sigfpe in unix.
Was there ever a source drop for VMS on vax? Probably hard to impossable to figure out if not
Early versions of Microsoft Flight Simulator included a handler for the divide exception, which adjusted the result to +/- "infinity" (for a 16-bit signed integer, 32767 or -32768). The rest of the code relied on this in order to work correctly, and it was more efficient to take advantage of the processor's microcode doing this check rather than coding it explicitly before every division.
So even if it doesn't make mathematical sense, being able to continue after this type of exception is a useful feature to have.
>(and if you ignore SIGSEGV, it is considered perfectly acceptable that your program spins in a SIGSEGV loop until you kill it.)
This, on the other hand, shouldn't ever be acceptable. If a fatal-by-default signal is just ignored, it should always terminate the process.
edit: not to dismiss kernel programmers, you people are awesome!
It is so easy to learn x86 assembly that way, and actually understand WHY BIOS was so important.
Os development is so easy nowdays with internet forums...
25 years ago there was an avalanche of new operating systems and if somebody asked me at that time, I was sure we will have much better operating systems in the future using fresh ideas.
I am not saying UNIX is bad, just that I would like to see some advancements in the OS area, beside improving UNIX kernels and APIs.
https://doc.cat-v.org/bell_labs/good_bad_ugly/
Do you have a link?
I initially thought the containerization movement of the early 2010s would be the first step toward redefining the OS—a way to finally slim things down. Instead, it just became a more efficient way to pack up the same baggage. We created a "reduction" in deployment complexity, but we haven't seen a continued effort to use those tools to actually change the paradigm.
I expected vertically integrated systems to become the norm by now—where building an executable would be an experience similar to containerization, but resulting in a lean, data-centric unikernel.
Instead, we are burning CAPEX on YAML sidecars in K8s clusters and N-tier abstractions that exist solely due to the large heterogeneity of the deployments that they never should have entered in the first place. We are spending more energy on the friction between layers than on the actual business of computation.
I was hoping for a return to sanity with the DBOS [1] research, looked like an attempt to rethink systems from first principles. But it seems that effort hasn't fully kicked off in the way the industry desperately needs.
[1]: https://dsail.csail.mit.edu/index.php/dbos/
Ask yourself which one is easier to diagnose and debug.
Which ones? I can only think of maybe Microsoft Singularity in 2003, and hobby OS Syllable. Neither were particularly innovative - the managed code thing had been done before with Inferno, and Syllable was heavily inspired by BeOS.
0. https://sel4.systems/
1. https://www.lionsos.org/
2. https://genode.org/
"When running on real hardware console output will be over serial."
> 1.
Seems to be a variant of "0" running on "Odroid-C4."
> 2. https://genode.org/
This one looks more polished.
Most of the people today are afraid to build OSs so they stick to virtual machines. An OS without drivers is not an OS.
Was there ever a source drop for VMS on vax? Probably hard to impossable to figure out if not
apparently some at some point?