OSDev.org

Oc, who uses old 32-bit CPUs nowadays ??
Simply, they are much slower.

You may use twice the ram because register size is doubled in long mode, but performance increases !
and I think RAM is much cheaper these days, I recently upgraded my PC from 8GB to 16GB of RAM for 30$.

I personally as an optimization, highly use registers to minimize memory accesses and that makes the function alot faster.


MMIO Pcie includes more space in the device configuration space, so if available it is recommended to use it anyway, for another reason MMIO is faster on PCI because you don't have to make multiple requests to read/write an unaligned value.

AndrewAPrice wrote:This is a bit of a silly argument because one could also argue to build a real mode OS and if you need anything better something is wrong with you...

I haven't owned an x86 processor that didn't support long move since the mid 2000s - some 17 years ago. I don't expect the audience of my OS (which honestly is just me) will want to run it on a pre 64-bit x86 processor.

That's a bad comparison. A real mode OS cannot take advantage of modern hardware because it cannot access all memory and even cannot use a lot of modern hardware. There is no such disadvantage of using protected mode. Protected mode can access all physical memory and handle all modern hardware. I'll even claim that long mode lack features present in protected mode which is the primary reason I'm not interested in long mode.

Also, you can emulate real mode in protected mode but not in long.

As for running on hardware that doesn't support long mode, we have two platforms in that category. On that use a modern multicore processor that doesn't run in long mode and the other is one with PIC controller and legacy hardware.

Protected mode lacks ip-relative addressing. That’s a significant disadvantage.

Protected mode also requires the existence of at least one GDT and one IDT, which are just a bloated waste of bytes that could better be used for something else.

The GDT and LDT is the primary reason why protected mode has features not supported in long mode. It also makes IP relative addressing unnecessary as segment register bases are more useful and also provide protection.

devc1 wrote:
MMIO Pcie includes more space in the device configuration space, so if available it is recommended to use it anyway, for another reason MMIO is faster on PCI because you don't have to make multiple requests to read/write an unaligned value.

That's quite irrelevant since configuration space is only accessed during initialization.

rdos wrote:It also makes IP relative addressing unnecessary as segment register bases are more useful and also provide protection.

Segmentation... we had a conversation about that a while ago. IMO, IP-relative addressing is simpler and more elegant than segmentation's mess.

My guy is just smashing everyone's comments, NOO: !! 32 Bit OSes ARE BETTER !!

Why do you even talk about modern hardware ? My PC which by the way is ten years old has an option that sets all the PCI devices above the 4GB area, and it is forced when you enable secure boot (MMIO Assignement mode : LEGACY/64 Bit EFI). So don't dream about making devices work on any PC with modern security features if you have a 32 bit OS. It's kinda forced to use 64 bit nowadays.

rdos wrote:As for running on hardware that doesn't support long mode, we have two platforms in that category. On that use a modern multicore processor that doesn't run in long mode and the other is one with PIC controller and legacy hardware.

In my household, my x86 devices all support long mode, and everything else is ARM (Raspberry Pi, MacBook, smart phones). So for greatest compatibility of devices, I should target ARM?

An argument you could make is "by building for protected mode, you support all x86-64 hardware automatically, but by building for long mode, you'd have to backport if you wanted to support 32-bit x86."

You're right. My counterargument (that others have made) is that at some point it's worth picking a cutoff point so you don't have to support all of the legacy ways of doing things. Choosing long mode as the cutoff point is good because it's pretty well advertised what are 32-bit or 64-bit CPUs.

I should target ARM?

Why not ? However, the only thing that I hate in arm is that arm is a RISC architecture, which makes it lower in performance than CISC cpus like x86. I'm I right ?

devc1 wrote:

I'm I right ?

No, you are wrong.

devc1 wrote:My guy is just smashing everyone's comments, NOO: !! 32 Bit OSes ARE BETTER !!

Why do you even talk about modern hardware ? My PC which by the way is ten years old has an option that sets all the PCI devices above the 4GB area, and it is forced when you enable secure boot (MMIO Assignement mode : LEGACY/64 Bit EFI). So don't dream about making devices work on any PC with modern security features if you have a 32 bit OS. It's kinda forced to use 64 bit nowadays.

I already boot with 64-bit UEFI, and devices above 4G is not a problem (PAE paging).

What if a high-end server computer with 20 hard drives and 64 gb of RAM. What would you do in this case ?
I think this is one of the limitations that 64 bit mode addresses ?

devc1 wrote:What if a high-end server computer with 20 hard drives and 64 gb of RAM. What would you do in this case ?
I think this is one of the limitations that 64 bit mode addresses ?

Not at all. My new disc buffering scheme will use physical address, not linear. File systems will be run the "micro kernel" way in their own processes having 2G of private linear memory. That's enough to cache meta data for any reasonable file system. Of course, each of the hard drives will have their own server process.

I don't think the issue is so much what cannot be done with protected mode, but rather how long protected mode will work and possible drawbacks performance wise as Intel and AMD optimize their processors for long mode.

AndrewAPrice wrote:

rdos wrote:As for running on hardware that doesn't support long mode, we have two platforms in that category. On that use a modern multicore processor that doesn't run in long mode and the other is one with PIC controller and legacy hardware.

In my household, my x86 devices all support long mode, and everything else is ARM (Raspberry Pi, MacBook, smart phones). So for greatest compatibility of devices, I should target ARM?

An argument you could make is "by building for protected mode, you support all x86-64 hardware automatically, but by building for long mode, you'd have to backport if you wanted to support 32-bit x86."

You're right. My counterargument (that others have made) is that at some point it's worth picking a cutoff point so you don't have to support all of the legacy ways of doing things. Choosing long mode as the cutoff point is good because it's pretty well advertised what are 32-bit or 64-bit CPUs.

Well, maybe for a new design that's reasonable. I started my OS project 1988, after having acquired a very expensive 386SX motherboard. While not much is left since that time, the OS is used on thousands of installations, some which have hardware that doesn't work with long mode. At this point, I'm not very interested in starting a new OS project, as I'm sure it will not be used by anybody else, and my own private needs doesn't require ARM or long mode. So, I will continue to develop my protected mode OS as long as I'm motivated and need new features.

My main point is that people that already work on protected mode OSes, and like me, have considerable amounts of code in assembly, won't need to switch to long mode anytime soon. Unless they want to start from scratch and never get to the point of something useful. Actually, you cannot restart once in a while and expect to build something useful. I never did a full restart, even if I have made considerable redesigns from time to time.

My current project is to port OpenSSL, as I want to be able to connect to and host https websites. I also need this to connect to various Internet services. It's working pretty well, but the Posix socket model is a bit of a problem.

SSL/TLS is an interesting component in the context of services. Where should it be put? What is the interface? This is not an easy issue since there will be a need to sync the implementation with OpenSSL from time to time to keep up with security patches. My current model is to link the library with the application, but I dont like that design too much. It should be a driver in the OS.

I also think people should not be so strict about monolithic vs microkernel designs. My opinion is that some things are better done with microkernel designs while others are better done the monolithic way. The service interfaces should not depend on how they are implemented.