Welcome • User Guide
ToS • Privacy • Canary
Donate • Bugs • License

©2026 Poal.co

289

I've been playing around with ZenithOS, a fork of TempleOS. I was reading their road map. A lot of it made sense. But then out of nowhere it said "drop support for all floating point types".

Here is the full roadmap:

  • AHCI driver that is capable of reading and burning CD/DVD discs, and can also work with RW discs.

  • Speed up the OS by doing compiler optimizations like register arguments.

  • Drop floating point support completely.

  • Add either SSE or AVX support (not both) to the assembler/compiler, for working with large integers.

  • Write a new 32-bit color graphics library that uses the added SIMD instructions. Refresh DolDoc for the following:

  • Build a simplistic GUI framework that integrates with DolDoc and the terminal using the new graphics library.

  • Add Intel HD Audio support.

  • Write drivers for the 5 most common ethernet cards.

  • Create a clean and robust networking stack that supports raw sockets, TCP, UDP, IP, ICMP, DHCP, and an HTTP library. Perhaps we can avoid Berkeley Sockets and create our own system?

  • Write applications using this networking stack.

  • Write a JSON library, so REST APIs can be used.

  • Drop FAT32 and maybe RedSea, replace with exFAT and proper ISO9660 support.

  • Whole system VCS, with root being top-level directory. Stored repo inside the OS, you can checkout any commit onto another partition and boot it to see what the OS was like in that commit.

  • Pull updates directly onto root filesystem from network. (it's a repo source tree after all).

  • At this point, bigger fish in the pond can be eyed. Perhaps support for USB keyboard and mice, and native USB mass storage support, significant code clean up and refactoring.

  • Port to other architectures??

Do you see any benefit?

I've been playing around with ZenithOS, a fork of TempleOS. I was reading their road map. A lot of it made sense. But then out of nowhere it said "drop support for all floating point types". Here is the full roadmap: - AHCI driver that is capable of reading and burning CD/DVD discs, and can also work with RW discs. - Speed up the OS by doing compiler optimizations like register arguments. - Drop floating point support completely. - Add either SSE or AVX support (not both) to the assembler/compiler, for working with large integers. - Write a new 32-bit color graphics library that uses the added SIMD instructions. Refresh DolDoc for the following: - Build a simplistic GUI framework that integrates with DolDoc and the terminal using the new graphics library. - Add Intel HD Audio support. - Write drivers for the 5 most common ethernet cards. - Create a clean and robust networking stack that supports raw sockets, TCP, UDP, IP, ICMP, DHCP, and an HTTP library. Perhaps we can avoid Berkeley Sockets and create our own system? - Write applications using this networking stack. - Write a JSON library, so REST APIs can be used. - Drop FAT32 and maybe RedSea, replace with exFAT and proper ISO9660 support. - Whole system VCS, with root being top-level directory. Stored repo inside the OS, you can checkout any commit onto another partition and boot it to see what the OS was like in that commit. - Pull updates directly onto root filesystem from network. (it's a repo source tree after all). - At this point, bigger fish in the pond can be eyed. Perhaps support for USB keyboard and mice, and native USB mass storage support, significant code clean up and refactoring. - Port to other architectures?? Do you see any benefit?

(post is archived)

You are currently inside a comment thread.
Click here to see all the comments (23).
[–] • 0 pt

So in the context of TempleOS/ZenithOS there is no kernel vs user land. Everything is kernel. It's basically if your kernel had JIT compiling and then you could execute C on the shell at the kernel level, line by line.

[–] • 0 pt (edited )

Well, in that case you have to stop using floating point entirely to get a performance benefit. Some CPUs support lazy floating point context save/restore, wherein the CPU detects whether a thread has used the floating point registers and sets a flag. When the OS goes to context switch, it can decide whether to save/restore FPU registers based on whether or not the previous/next thread used them. If most of your threads use them, say because shared libraries use them, you may reap little benefit. If you can't detect usage, and you have the FPU enabled, you have to assume they are used. If they are not usable, then you just ignore the FPU entirely.

Btw an option for C programs that depend on float support is FPU emulation. It's costly in terms of performance, but mechanisms for it are well established.