Intel propose simplified X86-S

[songziming]

link here: https://www.intel.com/content/www/us/en ... cture.html

Intel thinking about removing deprecated features like real mode, ring 1&2, leaving only 64-bit mode. (32-bit application still works under compatibility mode)

What do you think of it, will it make osdev easier?

[AndrewAPrice]

Dropping real mode and protected mode support will likely make processors simpler, which means they'll be faster and cheaper.

What do you think of it, will it make osdev easier?

I load my 64-bit microkernel with GRUB. This is my code that runs first and sets up the bare minimum to enter long mode. Once in long mode, I never touch 16-bit or 32-bit code again.

[rdos]

link here: https://www.intel.com/content/www/us/en ... cture.html

Intel thinking about removing deprecated features like real mode, ring 1&2, leaving only 64-bit mode. (32-bit application still works under compatibility mode)

What do you think of it, will it make osdev easier?

A really bad proposal. For one, it will break everything that runs today, perhaps excluded 64-bit EFI OSes that only use a single processor core.

Most of the proposed removals will have no or little effect on processor complexity. For instance, if the processor still needs to support loading FS & GS in compability mode, then the full segmentation support is needed. There is no logic in why CS, DS, ES and SS cannot handle segment loads (when FS and GS still must). This probably leads to more complexity not less.

There is also no logic why protected mode (compability mode) cannot work in kernel space, and there is additionally no logic why only two rings would be supported. This doesn't lead to a less complex processor, rather to the contrary since these cases must be detected and caused to fault.

I cannot see this being implemented in a real CPU anytime soon. First, all OSes that want to operate on it will need to handle how to start additional cores, and the new method described doesn't work on today's CPUs. Forget about GRUB and legacy booting, which many modern BIOSes still support.

Hopefully, AMD will not break protected mode like this, and then I can still run my OS on AMD. I'm not going to waste any time on a 64-bit OS.

[rdos]

Dropping real mode and protected mode support will likely make processors simpler, which means they'll be faster and cheaper.

Not really. Since they don't want to drop compatibility mode, and the ability to load FS and GS from the GDT/LDT, then they need to retain the segmentation code. They would need to drop compatibility code to be able to reduce the complexity significantly, but that would make all 32-bit applications impossible to run without an emulator. Dropping compatibility mode will probably happen at some point, but I think it is still too early for such a drastical step.

Besides, most of the segmentation support probably is not in hardware, but in microcode, particularly in Intel processors that have very poor segmentation performance already.

What do you think of it, will it make osdev easier?

I load my 64-bit microkernel with GRUB. This is my code that runs first and sets up the bare minimum to enter long mode. Once in long mode, I never touch 16-bit or 32-bit code again.

You will need to load your OS using a 64-bit EFI loader. Legacy boot no longer will work.

[Octocontrabass]

For one, it will break everything that runs today, perhaps excluded 64-bit EFI OSes that only use a single processor core.

That's fine, there's still plenty of time for current OSes to be updated.

There is no logic in why CS, DS, ES and SS cannot handle segment loads (when FS and GS still must). This probably leads to more complexity not less.

CS, DS, ES, and SS are all implicitly used by various instruction addressing modes. All of that logic - which can't be entirely in microcode because it's so fundamental to x86 - can be simplified because the implicit segment no longer matters; only explicit FS and GS prefixes can impact the effective address.

There is also no logic why protected mode (compability mode) cannot work in kernel space, and there is additionally no logic why only two rings would be supported. This doesn't lead to a less complex processor, rather to the contrary since these cases must be detected and caused to fault.

You're either underestimating the complexity of all those rarely-used modes or overestimating the complexity of faulting on attempts to switch to them.

I cannot see this being implemented in a real CPU anytime soon.

It won't be. This kind of change takes a while to make it to hardware.

First, all OSes that want to operate on it will need to handle how to start additional cores, and the new method described doesn't work on today's CPUs.

That's fine, ACPI provides a method that does work on today's CPUs. The only part that has to change is the switch between 4-level and 5-level paging.

Forget about GRUB and legacy booting, which many modern BIOSes still support.

You know GRUB supports UEFI, right? And many modern PCs no longer include a CSM (or it doesn't work because some component doesn't have a legacy option ROM). Multiboot won't work, but Multiboot was never very good in the first place.

Hopefully, AMD will not break protected mode like this, and then I can still run my OS on AMD.

AMD is definitely going to follow Intel's lead here.

[AndrewAPrice]

For one, it will break everything that runs today, perhaps excluded 64-bit EFI OSes that only use a single processor core.

Not sure if this is a true concern for Intel. Windows and Linux will have support by the time the first commercial x86-S CPUs go on sale. For most users, this is good enough.

It sucks for some users, but perhaps someone will just make a minimal Linux distro that starts a full-screen QEMU so you can run your real mode OS.

You will need to load your OS using a 64-bit EFI loader. Legacy boot no longer will work.

Yes. Sorry, my point was my non long-mode code was isolated to a single file, demostrating how insignificant (compared to the rest of the OS in terms of volume of code) that first bootstrap is. EFI will be different, but basically efi_main's job will be to get the system in the same state as my multiboot entry point before calling kmain.

[rdos]

For one, it will break everything that runs today, perhaps excluded 64-bit EFI OSes that only use a single processor core.

That's fine, there's still plenty of time for current OSes to be updated.

There is nothing to update to. The flat memory model of long mode is a nightmare for creating a stable OS. x86-64 largely is a 32-bit environment with 64-bit addons.

First, all OSes that want to operate on it will need to handle how to start additional cores, and the new method described doesn't work on today's CPUs.

That's fine, ACPI provides a method that does work on today's CPUs. The only part that has to change is the switch between 4-level and 5-level paging.

ACPI is software, not hardware, and so it doesn't matter. Besides, do any major OS use ACPI for starting cores?

Hopefully, AMD will not break protected mode like this, and then I can still run my OS on AMD.

AMD is definitely going to follow Intel's lead here.

I'm not convinced. AMD didn't follow Intel when they launched a completely new CPU for the 64-bit market, rather took the lead to extend x86 to 64-bit. AMD also have reasonably fast segmentation support on modern CPUs, and so probably have less microcode in the area.

[rdos]

For one, it will break everything that runs today, perhaps excluded 64-bit EFI OSes that only use a single processor core.

Not sure if this is a true concern for Intel. Windows and Linux will have support by the time the first commercial x86-S CPUs go on sale. For most users, this is good enough.

It sucks for some users, but perhaps someone will just make a minimal Linux distro that starts a full-screen QEMU so you can run your real mode OS.

My OS is 32-bit protected mode, and no emulator can run it AFAIK. Mostly because emulators have faulty segmentation support.

However, I'm not concerned about that. It will take decade or two before these CPUs are mainstream, and I can buy the hardware I need well before that happens. I will retire from professional software development within a decade, and I'm sure I have more interesting stuff to do than to waste my time on poor CPU designs.

[Octocontrabass]

The flat memory model of long mode is a nightmare for creating a stable OS.

That doesn't seem to stop anyone on non-x86 CPUs.

Besides, do any major OS use ACPI for starting cores?

Linux does.

[sounds]

Forget about GRUB and legacy booting, which many modern BIOSes still support.

You know GRUB supports UEFI, right? And many modern PCs no longer include a CSM (or it doesn't work because some component doesn't have a legacy option ROM). Multiboot won't work, but Multiboot was never very good in the first place.

Octocontrabass, I appreciate all you contribute, so can you please clarify what you think "many modern PCs no longer include a CSM" entails? Like, which products are you seeing?

nvidia still relies on Boot Mode = Legacy/CSM: https://www.guru3d.com/news-story/nvidi ... ues,3.html

MSI shipped with Boot Mode = Legacy/CSM as the default in 2021 -- a later update changed that, causing tons of support issues: https://www.reddit.com/r/MSI_Gaming/com ... t/jh0doyj/

Should I go on?

[sounds]

Linux does.

Not to be pedantic, but that source code kind of contradicts what you're saying:

Code: Select all

	 * The CPU being woken up is essentially in a spin loop waiting to be
	 * woken up. It should not take long for it wake up and acknowledge by
	 * zeroing out ->command.

So, if there's a BIOS bug and the CPU doesn't respond to the ACPI wakeup request... What will your OS do then?

What if it's a chromebook and doesn't support the ACPI wakeup mailbox?

etc.

[rdos]

Forget about GRUB and legacy booting, which many modern BIOSes still support.

You know GRUB supports UEFI, right? And many modern PCs no longer include a CSM (or it doesn't work because some component doesn't have a legacy option ROM). Multiboot won't work, but Multiboot was never very good in the first place.

Octocontrabass, I appreciate all you contribute, so can you please clarify what you think "many modern PCs no longer include a CSM" entails? Like, which products are you seeing?

nvidia still relies on Boot Mode = Legacy/CSM: https://www.guru3d.com/news-story/nvidi ... ues,3.html

MSI shipped with Boot Mode = Legacy/CSM as the default in 2021 -- a later update changed that, causing tons of support issues: https://www.reddit.com/r/MSI_Gaming/com ... t/jh0doyj/

Should I go on?

Kind of my experience too. I support both legacy/CSM boot and EFI boot (32-bit & 64-bit), but on a lot of PCs Legacy/CSM works while EFI doesn't, and so I boot several PCs using Legacy/CSM even if they are fairly new and support EFI booting. Part of the problem with EFI is that it is only tested with Windows, and some manufacturers try to lock down the machine to only Windows.

[sounds]

Part of the problem with EFI is that it is only tested with Windows, and some manufacturers try to lock down the machine to only Windows.

Intel is pretty good at open standards, so it's safe to expect x86-S to work with other OS's. It might not work very well though.

[rdos]

CS, DS, ES, and SS are all implicitly used by various instruction addressing modes. All of that logic - which can't be entirely in microcode because it's so fundamental to x86 - can be simplified because the implicit segment no longer matters; only explicit FS and GS prefixes can impact the effective address.

I don't think that logic is very complex, and it's only valid in protected mode / compatibility mode. The effective address will need to consider segment register bases (since FS & GS still can have non-zero bases), and so this cannot be removed. Hard-coding CS, DS, ES and SS with a zero base will not simplify anything, and might break code. The logic to load segment registers from GDT/LDT must be retained since FS and GS must operate with non-zero bases.

In the addressing area, all protected mode addressing modes must be retained for full compatibilty. It's possible that 16-bit addressing could be removed, but OTOH, there might be compilers that use 16-bit addressing with FS & GS, and so this could break things.

[rdos]

Part of the problem with EFI is that it is only tested with Windows, and some manufacturers try to lock down the machine to only Windows.

Intel is pretty good at open standards, so it's safe to expect x86-S to work with other OS's. It might not work very well though.

Intel has really poor display support for both EFI and VBE. They only support a small set of 4:3 resolutions even when there is a 16:9 display. AMD has a functional VBE and EFI that supports the relevant resolutions. Intel's linear frame buffer implementation generally sucks big time, and borders on unusable for resolutions higher than 800x600. AMDs linear frame buffer generally works well. In essence, you cannot use the native resolution (and speed might be severaly degraded) on a wide-screen Intel PC without a graphics driver in your OS. They also don't support the ACPI objects for controlling processor speeds, and so you need to install their processor driver for that. I wouldn't call that "good at open standards".