Is there any point in making a 32bit OS anymore?

[Owen]

No, it is actually a very good and long-time stable design, unlike most RISC processors that needs to be programmed in C (with frequent compiler rewrites). The only problem is that Intel tried to sabotage x86 architecture totally with Itanium, and when AMD later introduced their fix broke the chain of mode interoperability (IOW, 16/32 bit cannot live with 64 bit).

Most RISC designs have long term stability. Modern ARMv7 based processors are fully compatible with applications written for ARMv4, which was first released in 1994. (Support for ARMv3 apps has been removed, at least partially, because they have become extinct.) SPARCv9 will run code for the original SPARC just fine.

But there isn't any real mode interoperability on x86_32 anyway. 16-bit and 32-bit code can't interoperate for the simple reason that a 16-bit application doesn't know how to deal with a 32-bit address. 64 and 32-bit apps in practice interoperate as well as 16 and 32-bit ones did.

[rdos]

But there isn't any real mode interoperability on x86_32 anyway. 16-bit and 32-bit code can't interoperate for the simple reason that a 16-bit application doesn't know how to deal with a 32-bit address. 64 and 32-bit apps in practice interoperate as well as 16 and 32-bit ones did.

Not so. A 32-bit aware OS can service applications written for DOS, 16-bit protected mode, 32-bit protected mode and 32-bit flat mode just fine, without any type of emulation. The protected mode apps are handled by extending pointers to 16:32, while the real-mode one's are run in VM86-mode, and use segment translations. This is broken in 64-bit mode since selectors are no longer available, and protected mode cannot use 64-bit addresses or registers. Even VM86 mode is broken (not supported).

[Owen]

But there isn't any real mode interoperability on x86_32 anyway. 16-bit and 32-bit code can't interoperate for the simple reason that a 16-bit application doesn't know how to deal with a 32-bit address. 64 and 32-bit apps in practice interoperate as well as 16 and 32-bit ones did.

Not so. A 32-bit aware OS can service applications written for DOS, 16-bit protected mode, 32-bit protected mode and 32-bit flat mode just fine, without any type of emulation. The protected mode apps are handled by extending pointers to 16:32, while the real-mode one's are run in VM86-mode, and use segment translations. This is broken in 64-bit mode since selectors are no longer available, and protected mode cannot use 64-bit addresses or registers. Even VM86 mode is broken (not supported).

Selectors still exist. However, the limits are ignored, and the base is ignored unless you are loading FS or GS. There is nothing stopping a long mode OS supporting all protected mode applications.

As for real mode - are you serious? ...

[rdos]

Selectors still exist. However, the limits are ignored, and the base is ignored unless you are loading FS or GS.

Which means it is broken. When limit and/or base are ignored, the concept is broken. This was an arbitrary design-choice that was not necesary.

There is nothing stopping a long mode OS supporting all protected mode applications.

No, but a 32-bit OS cannot serve 64-bit applications without emulation. That is the primary reason why it is broken. This would have been perfectly possible by mapping the incoming 64-bit addresses to selectors in the 32-bit environment if the concept had been extended instead of broken.

[Combuster]

I see arguments for the sake of arguments here...

Please read up on your facts, rdos, and stop using circular arguments and red herrings, please.

Long mode was designed to run 32-bit and 16-bit applications natively without the need of going through actual mode changes. If you want to call that broken, fine, but the world minus you disagrees about that definition of "broken".

[Owen]

Selectors still exist. However, the limits are ignored, and the base is ignored unless you are loading FS or GS.

Which means it is broken. When limit and/or base are ignored, the concept is broken. This was an arbitrary design-choice that was not necesary.

The choice was made to simplify the processor and operating mode. In particular, the observation was made that no common operating system maintained segments in any way except vestigially to build a flat mode (Exception: EH and TLS - or, why FS and GS still have bases).

It is worth noting that modern x86 processors take penalties for segments with nonzero bases, in no small part due to the pipeline now being optimized for base=0. For example, AMDs take a 1 cycle hit on all branches, and many CPUs will add an extra cycle for nonzero bases in address calculations.

In other words: A feature was removed which was adding nothing to the architecture.

There is nothing stopping a long mode OS supporting all protected mode applications.

No, but a 32-bit OS cannot serve 64-bit applications without emulation. That is the primary reason why it is broken. This would have been perfectly possible by mapping the incoming 64-bit addresses to selectors in the 32-bit environment if the concept had been extended instead of broken.

Mac OS X 10.5 ("Leopard") is a 32-bit operating system which runs 64-bit applications natively. There is a small section of 64-bit mode code responsible for setting everything up and doing some translations, but the majority of the kernel is 32-bit. 10.6 has moved to being fully 64-bit.

[rdos]

The choice was made to simplify the processor and operating mode. In particular, the observation was made that no common operating system maintained segments in any way except vestigially to build a flat mode (Exception: EH and TLS - or, why FS and GS still have bases).

They have been looking too much on Microsoft OSes, which uses FS for TLS. Why else keep the base for FS and GS and not for CS, DS and ES?

It is worth noting that modern x86 processors take penalties for segments with nonzero bases, in no small part due to the pipeline now being optimized for base=0. For example, AMDs take a 1 cycle hit on all branches, and many CPUs will add an extra cycle for nonzero bases in address calculations.

That's also crappy. I might change the base for flat mode user mode to 0 instead, provided the DOS emulation support is not loaded. The primary reason why I won't load flat apps at 0 is that they should not have access to V86 interrupt-vectors, BDA and BIOS. But without this support, those areas will become just like any other area. Is the limit checking still done without penalties?

Mac OS X 10.5 ("Leopard") is a 32-bit operating system which runs 64-bit applications natively. There is a small section of 64-bit mode code responsible for setting everything up and doing some translations, but the majority of the kernel is 32-bit. 10.6 has moved to being fully 64-bit.

Interesting. Wonder how they did that. It would require some kind of mode-switch to/from IA32e mode (for every syscall) which probably won't be very efficient.

[Owen]

The choice was made to simplify the processor and operating mode. In particular, the observation was made that no common operating system maintained segments in any way except vestigially to build a flat mode (Exception: EH and TLS - or, why FS and GS still have bases).

They have been looking too much on Microsoft OSes, which uses FS for TLS. Why else keep the base for FS and GS and not for CS, DS and ES?

The Unix OSes also use FS for TLS (on 32-bit; on 64-bit they use GS). FS and GS are useful as extra base registers for structures. CS/DS/ES/SS are implicit in many instructions, and not useful when you are strongly deprecating segmentation

It is worth noting that modern x86 processors take penalties for segments with nonzero bases, in no small part due to the pipeline now being optimized for base=0. For example, AMDs take a 1 cycle hit on all branches, and many CPUs will add an extra cycle for nonzero bases in address calculations.

That's also crappy. I might change the base for flat mode user mode to 0 instead, provided the DOS emulation support is not loaded. The primary reason why I won't load flat apps at 0 is that they should not have access to V86 interrupt-vectors, BDA and BIOS. But without this support, those areas will become just like any other area. Is the limit checking still done without penalties?

Limit checking is still without penalty, to my knowledge. However, why does whether v86 support is loaded matter? Are you using one page table for all tasks? ...

Mac OS X 10.5 ("Leopard") is a 32-bit operating system which runs 64-bit applications natively. There is a small section of 64-bit mode code responsible for setting everything up and doing some translations, but the majority of the kernel is 32-bit. 10.6 has moved to being fully 64-bit.

Interesting. Wonder how they did that. It would require some kind of mode-switch to/from IA32e mode (for every syscall) which probably won't be very efficient.

You can download the source and look. My understanding is that, yes, it does involve a second mode switch; but XNU syscalls have never been a screamer anyway since they also involve a page table change.

[rdos]

Limit checking is still without penalty, to my knowledge. However, why does whether v86 support is loaded matter? Are you using one page table for all tasks? ...

No, but there is a set of different memory allocators that operate at different linear addresses. Below 1MB is the DOS allocator, above 16MB is the flat allocator, and in between a byte-level allocator primarily used for 16-bit protected mode. When DOS emulation is loaded, a set of addresses are set to fault on access to a monitor program (for instance BDA and V86 interrupt vectors). These will virtualize these resources. In a flat memory model, access of V86 interrupt vectors should page-fault. In fact, when base is set to 0 for flat user mode, the entire first 1MB should be set to page-fault. I can do this for every process created if DOS emulation is not loaded.

[prinzrainer]

I was going to write a 64-bit os...but i can't find a gcc(that compiles 64 bit code) that runs on windows...so i stick to 32 bit OS dev..btw does anyone has already compiled gcc(that compiles 64 bit code and it binutils) for windows?? i might go on to 64-bit development...

[JamesM]

This is the second time you've hijacked a thread with that comment; I silently deleted it last time.

If you have a question, make a thread and ask it. Don't hijack someone else's thread with your question. Nettiquette 101.