OSDev.org

On any reasonable modern processor you can rely on the existence of some sort of interrupt mechanism.

You cannot rely on any particular implementation of this mechanism being present. Each processor does things its own way.



On any modern processor intended for mobile, desktop, or server use you can rely on the existence of some sort of paging mechanism. You will also find paging on many, but not all, embedded processors. Unless you're developing an OS for embedded use, you should probably refuse to support processors that don't have paging, as it has significant benefits for reliability, security, and debugability, and non-embedded processors that don't have paging are going to be in very old, low-spec hardware.

That said, most (all?) processors will *not* have paging active at boot, so your early boot code will have to deal with a non-paged environment (unless you outsource that to an external bootloader), but early-boot code will tend to be architecture-specific anyway.

You cannot rely on any particular implementation of paging being present. Address space size, number of paging levels, and page size may all vary.



The only processor that you're likely to encounter with segmentation is an Intel processor. Every modern operating system for Intel processors just uses it in real mode at boot time, then, when switching to protected/long mode, sets up the minimum in terms of segmentation that is needed to run as if the segmentation system didn't exist, and then promptly forgets about segmentation. In long mode and compatibility mode, segementation only exists for historical reasons and you can't do anything with it other than setting up a flat address space and forgetting about segmentation. The only reason you would ever use segmentation on an Intel processor is if you're running in real mode or 16-bit protected mode for some reason.



That depends what you mean by "a serial I/O device". If you mean "an RS-232 device", no.



No, multiboot is entirely a software thing. It's also mostly an x86 thing. It could conceivably be adapted to non-x86 systems, but you're not even guaranteed to see it on x86 systems. In fact, any x86 system that ships with a proprietary OS (which is to say, Windows), will almost certainly *not* have a multiboot compliant bootloader unless the user puts it there. That said, if the user has installed Linux, there almost certainly will be a multiboot compliant bootloader (though, depending on how the user has things set up, it may not be the first bootloader to run), and if someone is trying out alternative OSes, they're likely to try out Linux before they try out your OS, so even though the general rule is "no, you cannot count on a multi-boot compliant bootloader", you probably can count on the people that are likely to try your OS having one (on x86).

Yeah, thinking in terms of "how many architectures can I support" is all wrong. Portability always sacrifices speed and the ability to exploit specific features of a CPU. That might be ok if you want something that is mediocre on many CPUs, but not otherwise. I only support x86 because only x86 has segmentation, which I consider a vital component of memory protection. I also rely heavily on assembler code instead of C, which I can do since I only support x86.

x86_64 does not support segmentation. You're basically saying "Rather than designing my kernel so that it can adapt to different scenarios I optimize for an architecture that have been obsolete for at least 10 years and today only serves a niche market".

I also really doubt the "portability hurts performance" statement. Supporting a feature on one architecture does not mean that you have to require it on every architecture. However it is very easy to convince me if that statement is indeed true: Just show me a single (general purpose) OS that exploits all the nice special features of x86 and outperforms Linux or Windows on common workloads (or even a single real-world workload; microbenchmarks don't count). Hint: You can't; performance depends on the design of your algorithms and not on "Let me use segmentation instead of paging".

I have created a new thread if you wish to continue this discussion without derailing this one.