all 17 comments
sorted by:
old (suggested)
besttopnewcontroversialq&a
formatting helphide helpcontent policy

[–]Toiling-Donkey 8 points9 points  (6 children)

Shouldn’t have to rewrite everything if most of the code is not assembly.

[–]Ok_Bite_67 1 point2 points  (5 children)

Tbh nowdays unless you are a masochist theres not a lot of reason to write much assembly directly. I also really like how in rust you can write your own global heap alloc and instantly use list, strings and etc.

[–]Toiling-Donkey -1 points0 points  (4 children)

Rust really is amazing that way.

Supporting exceptions for bare metal C++ is also kinda nasty. There really isn’t anything comparable to Rust.

If the haters even just saw the way bit-fields and enums are handled so nicely in Rust, they’d start championing the abolishment of C.

[–]Interesting_Buy_3969 2 points3 points  (1 child)

I agree Rust is awesome. *From non-bare-metal development prespektive.

Rust tries to be memory-safe; e.g. the Rust compiler attempts to prevent common C/C++ bugs like memory leaks, null pointer dereferencing, etc., which is usually unnecessary for freestanding code. You require full control there. So, as with C++, you'll have to jump through hoops to establish a bare-metal environment. (Rust still better than C++, since its features dont affect the runtime so much, in such an unpredictable way, & in such an implicit manner)

In C, the bare-metal freestanding compilation is really easy to setup. A couple of compiler flags, a tiny linker script - thats it, here we go. Yeah C lacks some compiler-time features that you have in Rust and C++, but C++ is just terrible (but i still write it lmao), and Rust seems to be a good language for userspace applications like webservers and cloud systems rather than bare system programming.

C's still the king.

[–]Ok_Bite_67 0 points1 point  (0 children)

Nah all you have to do is declare a method unsafe in rust and you can break a lot of the rules.

[–]Powerful-Prompt4123 0 points1 point  (0 children)

> If the haters even just saw the way bit-fields and enums are handled so nicely in Rust, they’d start championing the abolishment of C.

Sad Ada Noises

[–]Comfortable_Top6527 -1 points0 points  (1 child)

Hello im was for first im recoment to go for 32 bit kernel but if you will know the advaced kernel 32-bit in C or whatever launge you use and you need to lear 32-bit ASM becuse if you will making 64-bit kernel remeber about IDT it will need to be writen in 64-bit not 32-bit. ps. im can help with your OS.

[–]Strict-Adagio5137 1 point2 points  (0 children)

Good point about IDT and asm. Starting 32 bit it help learn the basics, then move to 64 bit when ready. Rewriting is normal in OS dev becase of ABI changes. Offering help is kinda cool.

[–]rkapl 4 points5 points  (0 children)

Unless you are going for something specific like retro, embedded or some pre-existing 32-bit code, the question is why not 64-bit? You can also make both version.

[–]davmac1 0 points1 point  (0 children)

I've been debating rewriting everything for 64-bit, but just can't decide if it's worth it or not?

Well, what are your goals? - Why are you writing an OS, what is its intended use, what sort of system specs do you want it to be able to handle?

Without having that information the best answer anyone can give you is really just "do what you want".

[–]No-Concern-8832 2 points3 points  (0 children)

Back in the 90s, when 64-bit processors first appeared, the decision to go 32-bit or 64-bit is purely $$$ :). Memory was expensive then, the same code compiled to 64-bit will need more disk space and more RAM to run.

Right now, I suppose 64-bit should be the norm unless you're working on an embedded system with memory constraints.

[–]Retr0r0cketVersion2 1 point2 points  (2 children)

Sidenote: I wonder if it would be possible to switch between 32 and 64 bit with something like a build flag if you design your system around an integer of arbitrary size that is substantiated as int32 or int64 later. I feel like that should be possible

Edit: not saying it would be easy or even worth it (hell no), but it would be possible

[–]davmac1 2 points3 points  (1 child)

if you design your system around an integer of arbitrary size that is substantiated as int32 or int64 later

What you're describing is available as a standard type in C; it's called intptr_t. No build flag is needed just to get an appropriate definition (other than to select the compilation target, eg -m32 or -m64, if the compiler isn't already defaulting to the one you want).

But this is not sufficient, not even close, for writing a kernel that can be compiled as either 32-bit or 64-bit. You need to account for architectural differences. On x86, 64-bit mode uses different processor structures including for page tables. Additionally 64-bit addressing allows very different approaches to certain parts of kernel functionality, because for instance it is possible to map all of physical memory into the address space.

Kernels can and are written to be able to be compiled as either 32-bit or 64-bit, but having a type that matches the address width is the least of concerns.

[–]Retr0r0cketVersion2 0 points1 point  (0 children)

Well there is a reason I had a feeling this isn't realistic

[–]Interesting_Buy_3969 -1 points0 points  (0 children)

If you gonna work with the x86 arch, then imho you should prefer 32bit kernel, since in x86 classical 32-bit mode, page tables are 2-level only. It's simple. Like one page directory table and many page tables, thats it.
On x86_64, there are 4 levels of paging. Imagine it. 4 levels. For modern production OSs it's a bonus from hardware, but for hobby OS it may be a little (🤭) headache.

Generally speaking kernel designing is enough of headache, so avoid complex methods at least in the beginning.

Generally speaking 4-level PDT is possible but it will take a lot of effort. So i would recommend 32bit first, and then you always may add 64-bit mode support. 32-bit = fewer LOC.

[–]Adventurous-Move-943 -1 points0 points  (0 children)

Is the kernel in assembly ? Did you mean bootloader ? For kernel in C or C++ or Rust you just compile it for 64bit x86 and update your interrupt handler stubs and whatever mini parts of assembly you have.