Why Tilck runs only on x86 (ia-32)?

[vvaltchev]

(Question moved from the main README.md file.)

[vvaltchev]

Actually Tilck runs only on x86 for the moment. The kernel was born as a purely
educational project and the x86 architecture was already very friendly to me at
the time. Moving from x86 usermode assembly to "kernel" mode (real-mode and the
transitions back and forth to protected mode for the bootloader) required quite an
effort, but it still was, in my opinion, easier than "jumping" directly into a
completely unknown (for me) architecture, like ARM. I've also considered writing
from the beginning a x86_64 kernel running completely in long mode but I
decided to stick initially with the i686 architecture for the following reasons:

• The long mode is, roughly, another "layer" added on the top of 32-bit
  protected mode: in order to have a full understanding of its complexity, I
  thought it was better to start first with its legacy.

• The long mode does not have a full support for segmentation, while I wanted
  to get confident with this technology as well.

• The long mode has a 4-level paging system, which is more complex to use that
  the classic 2-level paging supported by ia-32 (it was better to start with
  something simpler).

• I never considered the idea of writing a kernel for desktop or server-class
  machines where supporting a huge amount of memory is a must. We already have
  Linux for that.

• It seemed to me at the time, that more online "starters" documentation existed
  (like the articles on https://wiki.osdev.org/) for i686 compared to any other
  architecture.

Said that, likely I'll make Tilck to support also x86_64 and being able to run
in long mode at some point but, given the long-term plans for it as a tiny kernel
for embedded systems, making it to run on ARM machines has priority over supporting
x86_64. Anyway, at this stage, making the kernel (mostly arch-independent code)
powerful enough has absolute priority over the support for any specific architecture.
x86 was just a pragmatic choice for its first architecture.

[vvaltchev]

Updated answer (Nov 2024): Tilck runs also on RISCV64 now.
As mentioned in my previous answer, supporting just i386 has never been the long term plan.

[toncho11]

What about Tilck becoming an retro OS for 8088, 80286, 386 etc like https://github.com/ghaerr/elks ?

[vvaltchev]

Hello @toncho11, Elks looks super cool, thanks for the reference. I didn't know that project. About Tilck supporting older architectures, it actually crossed my mind and I did a bit of research on that a few years ago. It turned out that even going back from i686 to i586 would be a problem, because of the BIOS interrupts used by Tilck's bootloader. I played a bit with PCem. Indeed, it's not just about the instructions, but also the firmware available for a PCs of older generations. So, it would require some effort to get even i586 working, which is pretty close to i686. Beyond that, it's even worse. Going back to i486, not only the BIOS interrupts get further reduced, but we lose multiple instructions and most importantly we lose the support for the "big pages" (4 MB). I use those extensively during Tilck's initialization and to map memory for the page tables. Without that feature, I'd need to always use 2-level paging, which is inconvenient doing early setup and actually tricky a bit after that to map system's physical memory. I'd need to implement "bootstrapping paging" (aka "page‑table chasing"), which will be painful. Going back to i386 would be even worse, because not even CPUID exists. Plus, i386 has no cache, so no INVLPG instruction. More runtime trickery. Beyond that, on 80286 there is no virtual memory. Tilck need to actually support NOMMU systems to run there. That would be insanely hard to do.

Overall, given that ia32 has been practically dead for a long time now, if I have a bit of energy and free time, I'd spend effort on making x86-64 to work instead. Going back would be fun, but it would have a low ROI. In the long term, I'd like Tilck to continue working on real hardware and maybe one day even be able to do something useful, like run on a Raspberry Pi, have networking and storage. Running on ancient machines is not part of project's roadmap. I'd rather scale down the project on NOMMU Cortex-R systems, which are modern and might have a "real world" application than trying to support ancient systems.

Also, Elks is great for that. One more reason for me to not spend effort in that direction.

Said that, as a passionate software engineer, I believe that retro-computing is pretty cool as a hobby. Indeed, if I was retired, I would probably make it work at least on at least one IBM Thinkpad from the 90s, equipped with i586. That would give me enough satisfaction.

[vvaltchev]

@toncho11 Somehow related discussion: #186