Intel propose simplified X86-S

[AndrewAPrice]

AMD broke virtual 86 mode within long mode, but they didn't break virtual 86 mode within protected mode, neither did they break anything else. Basically, long mode was a pure addition that broke nothing. What Intel is proposing now is not only to break real mode, virtual 86 mode and 16-bit protected mode, but also 32-bit protected mode. They will even break compatibility mode and processor core initialization. If they get away with this, then x86 no longer is a backwards compatible processor, and why would people bother with it instead of moving to ARM?

At the time of introducing a new processor mode, it made sense to maintain backwards compatibility, mostly because it gave time for operating systems to adapt. (Especially in the DOS era where DOS ran in real mode, and allowed individual programs to switch to protected mode.) Now, it has been 20 years since x86-64 was released in 2003, and it would be safe to assume 95%+ of x86-64 desktop users run a long mode OS. For them, switching to x86-s would mean updating Windows, and nothing would break; they can still run all 32-bit and 64-bit Windows programs.

Also, we're at a point where we can emulate a 30 year old processor at reasonable speed, if someone wants to run 30 year old software. That's how people play 16-bit DOS games from the 90s on Windows 11.

So, Intel's target audience are these 95%. The boot process changes a little bit (from an OS implementation side) and nothing else breaks.

x86 is fairly unique in terms of backwards compatibility. With other architectures, OS's tend to be built for a specific iteration of the architecture and maybe you get user-space compatibility (e.g. ARM.) Apple hasn't been shy about completely ditching architectures for another.

[pvc]

It should have been done long time ago. And for legacy/compatibility, emulation is good enough. It was good enough even back when 64 bits were introduced to x86 line in early 2000s.

[nullplan]

It should have been done long time ago. And for legacy/compatibility, emulation is good enough. It was good enough even back when 64 bits were introduced to x86 line in early 2000s.

Back in those days, UEFI was but a dream in an Intel engineer's mind. Most computers booted with BIOS. And most BIOS code was created by AMI, Phoenix, and Award, back in the eighties, all in assembler, and the contents of the BIOS ROM would be created by concatenating the right assembler files in the right order. Further more, all graphics cards only came with a video BIOS extension. And you can bet that all of those components used some dirty tricks somewhere that would have been impossible in the more regulated environment of UEFI. So no BIOS - no graphics.

In short, I believe the past couple of decades were necessary to get UEFI accepted enough that the boot process is no longer dependent on PC architectural internals enough that real mode can be axed.

[sounds]

I see posts from nullplan, pvc, AndrewAPrice, BigBuda and Octocontrabass giving their opinion (sometimes with a slightly mocking tone) that we all need to think the same as they do.

I've provided examples of large, for-profit companies (MSI, nvidia), a small company (below [1]) and an indie developer (xorvoid.com) with an innovative new release, all still using the legacy mode that X86-S is removing.

You do realize that your opinion doesn't mean anything to the people in these examples I've provided, right? Just because you, personally, don't care any more about these legacy modes doesn't make you the authority or give you the moral high ground when removing it. If intel wants to ditch their legacy compatibility, they will, regardless of your opinion or these other companies. And in response, the market is already poised to move to arm -- the reasons won't matter at that point.

[1] https://arstechnica.com/gadgets/2023/05 ... kb-of-ram/

[nullplan]

I see posts from nullplan, pvc, AndrewAPrice, BigBuda and Octocontrabass giving their opinion (sometimes with a slightly mocking tone) that we all need to think the same as they do.

If that is your opinion of me, we are looking at a miscommunication. I never intended to force anyone to believe as I do, merely to persuade. You are free to believe whatever you want. I however am free to speak my mind.

I've provided examples of large, for-profit companies (MSI, nvidia), a small company (below [1]) and an indie developer (xorvoid.com) with an innovative new release, all still using the legacy mode that X86-S is removing.

You do realize that your opinion doesn't mean anything to the people in these examples I've provided, right?

Exactly. Which means they won't care about what a pseudonym on a half-forgotten internet message board thinks. Note that that is both of us. All of us, actually. So what is your point? Is my opinion less valid because I lack the funds of MSI or nVidia? We are merely exchanging viewpoints here, and nothing we say will have any bearing on how this whole situation shakes out. If Intel does want to go through with this, they will, no matter what rdos says. I am merely expressing approval.

Just because you, personally, don't care any more about these legacy modes doesn't make you the authority or give you the moral high ground when removing it. If intel wants to ditch their legacy compatibility, they will, regardless of your opinion or these other companies. And in response, the market is already poised to move to arm -- the reasons won't matter at that point.

I, personally, am not removing anything. I doubt anyone will move to ARM over this. The number of things that would break in a move to x86-s is far smaller than the number of things that would break in a move to ARM. Companies won't do it even just for the risk. Although I have heard of the x86 simulator Apple has made for their M1-based systems, that is apparently the bee's knees in terms of emulation.

I know that there is a market for modern legacy hardware. Hardware still capable of connecting ISA cards, and having four ISA serial ports and stuff like that, but recently manufactured, so you don't have the problems of retro hardware (like dry capacitors, rotten traces, three decades worth of dirt, &c.) So if X86-S does come, I think there will be a market for X86 classic CPUs. I doubt that companies that need the old modes actually need upgrades to their CPUs, right? They can just keep using the same model they have now forever. That way, everyone can be served. Meanwhile, us normal people get to enjoy simpler CPUs that are cheaper to make (and thus possibly cheaper to purchase).

[Octocontrabass]

I've provided examples of large, for-profit companies (MSI, nvidia), a small company (below [1]) and an indie developer (xorvoid.com) with an innovative new release, all still using the legacy mode that X86-S is removing.

Your examples don't really prove your point, though. MSI switched away from legacy mode. NVidia suggested it as one of several possible workarounds for a firmware bug; the other workarounds don't rely on anything legacy. The unnamed Book8088 company is producing hardware aimed at a specific niche audience, not a device meant to compete with other general-purpose computers. The indie developer is knowingly targeting obsolete hardware, the same as the indie developers who write NES and Atari games.

Just because you, personally, don't care any more about these legacy modes

I guess it has been a while since I've worked on my legacy BIOS bootloader.

And in response, the market is already poised to move to arm

I don't see why X86-S would be the deciding factor. Actually, I'd expect the opposite: X86-S should allow Intel to make even faster CPUs thanks to the simplified logic design, so the market will be encouraged to stick with x86.

[sounds]

And in response, the market is already poised to move to arm

I don't see why X86-S would be the deciding factor. Actually, I'd expect the opposite: X86-S should allow Intel to make even faster CPUs thanks to the simplified logic design, so the market will be encouraged to stick with x86.

X86-S will signal that the instruction set architecture is no longer backward compatible for the first time. The market already has a non-backward-compatible instruction set with a much deeper pool of suppliers than x86 -- arm.

[Octocontrabass]

X86-S will signal that the instruction set architecture is no longer backward compatible for the first time.

This is not the first time x86 has changed in a backwards-incompatible way. The first time was the 286, which changed IDIV, PUSH, the LOCK prefix, and shift/rotate instructions. It also added an instruction length limit, changed the behavior of #DE, and changed the behavior of address wraparound in a way that broke so many programs IBM chose to implement the A20 gate as a workaround.

This is not the second time x86 has changed in a backwards-incompatible way. The second time was the 386, which changed the LOCK prefix again and changed segmentation in a way that broke probably the most popular Unix available for PCs at the time.

This is not the third time x86 has changed in a backwards-incompatible way. The third time might have been the Pentium Pro, which changed the requirements to enable paging in a way that breaks at least one OS.

This is not the fourth time x86 has changed in a backwards-incompatible way. The fourth time that I know of was the Haswell microarchitecture, which no longer keeps track of enough information for 16-bit floating-point exception handlers to function correctly.

For more than 99% of Intel's customers, X86-S is not going to change anything. Their OS will be updated to support it before they buy their first X86-S CPU, and their applications won't know the difference.

[linguofreak]

X86-S will signal that the instruction set architecture is no longer backward compatible for the first time. The market already has a non-backward-compatible instruction set with a much deeper pool of suppliers than x86 -- arm.

Whatever the case for the ISA itself, few, if any, x86 machines built in the last 10 years and not explicitly marketed to retrocomputing enthusiasts are capable of booting PC-DOS 1.0 (on account of other hardware apart from the CPU), so back compatibility has already been slipping for a while on the PC architecture and nobody's been missing it. Except for a few retrocomputing nerds like myself (or you), nobody is really looking for any more in terms of back-compatibility on x86 than the ability to run 32-bit Windows applications, and that's the whole reason that x86-S is even being proposed. And even I don't need 16-bit back-compatibility on my main machine, or, honestly, on a machine using a CPU manufactured this year. A few hardware vendors selling crap hardware running crap firmware might run into trouble because of their own bad decisions when x86-S CPUs hit the market, but manufacturers selling specifically to the retrocomputing market are not among them: they're probably already scrounging discontinued x86 models anyway instead of using new parts. In any case, ARM may end up outcompeting x86 in the long run, but x86 dropping 16-bit compatibility will lose them negligible market share in that competition.

[sounds]

2023 and the use of 16 bit mode continues:

Cooler Master prebuilt systems using the Gigabyte B760-DS3H AC DDR4 need the CSM Compatibility Support Module enabled in the BIOS for RTX 3060 GPUs to resolve an issue with DisplayPort. In other words, (most likely) the video card's CSM BIOS module works while the EFI BIOS module does not.

https://youtu.be/t036sCrXnFc?t=302

[Ethin]

I'd be all for Intel changing x86-s to removing both 16-and 32-bit mode entirely so that the processor initializes directly into 64-bit mode. No GDT, No LDT, no TSS, absolutely no compatibility support in the processor whatsoever. Just pure AMD64. If Apple can make an emulator that emulates x86 fast enough that the majority of people don't notice any performance problems, I don't see why the OSs couldn't implement a compatibility mode emulation subsystem for those apps that genuinely need it, or some "on-the-fly" code translation mechanism. It would dramatically simplify the design entirely, it's what pretty much every modern architecture does nowadays (if you buy a RISC-v RV64 processor, your not going to be booting into RV32 mode, your going to be booting directly into RV64 mode and you can't say "Hey I want RV32 mode" -- unless there's an implementation that lets you do it and I just don't know about it), and it would simplify OS dev as well. If they want to keep paging as a requirement of long mode, then just have the processor initialize with a flat address space by default and allow the executive to adjust that as necessary. But I doubt this'll happen any time soon.

[sounds]

Interesting article today on Hackaday. "Why x86 needs to die"

By which the author means, X86-S is their preferred future.

My opinion is diametrically opposed, but it's great to see that in 2024, 16-bit x86 code still captures everyone's attention!

[rdos]

I think they could remove real mode and 16-bit instruction codings too, but X86-S breaks compatibility mode as well. For no good reason.

Still, X86-S is not likely to help in the competition against ARM and RISC-V. The markets they already have will not go back to x86-S. X86-S seems more like a desperate move that won't do any good, and instead will be the end of x86 since so much will be broken.

For me personally, I'll stick to x86 segmentation for its superior features that allow isolating kernel drivers from each other, something that x86-64, x86-S, ARM and RISC-V cannot handle.

[Octocontrabass]

X86-S breaks compatibility mode as well. For no good reason.

I'm sure I said this before, but Intel has already done the math and worked out that losing you as a customer is less expensive than continuing to implement those functions in their CPUs.

Still, X86-S is not likely to help in the competition against ARM and RISC-V.

What competition? Intel is already working on fabricating ARM CPUs, and if RISC-V becomes popular enough, I'm sure Intel will fabricate RISC-V CPUs too.

For me personally, I'll stick to x86 segmentation for its superior features that allow isolating kernel drivers from each other, something that x86-64, x86-S, ARM and RISC-V cannot handle.

You can get the same isolation by writing code in a memory-safe language and using the compiler's runtime bounds checks, and then you're not limited by the number of segment registers or the number of descriptors.

[rdos]

X86-S breaks compatibility mode as well. For no good reason.

I'm sure I said this before, but Intel has already done the math and worked out that losing you as a customer is less expensive than continuing to implement those functions in their CPUs.

Perhaps, but there are other x86 manufacturers (AMD). If Intel implements X86-S, then AMD might not, and then I can continue to use AMD.

Still, X86-S is not likely to help in the competition against ARM and RISC-V.

What competition? Intel is already working on fabricating ARM CPUs, and if RISC-V becomes popular enough, I'm sure Intel will fabricate RISC-V CPUs too.

Sure. Intel couldn't even come up with a 64-bit implementation that was somewhat backwards compatible, and instead tried to lock-up people on their own 64-bit design that had no compatibility with decent performance. So, it wouldn't surprise me if Intel wants x86 to disappear from the market.

For me personally, I'll stick to x86 segmentation for its superior features that allow isolating kernel drivers from each other, something that x86-64, x86-S, ARM and RISC-V cannot handle.

You can get the same isolation by writing code in a memory-safe language and using the compiler's runtime bounds checks, and then you're not limited by the number of segment registers or the number of descriptors.

Not at all. The alternatives are interpreted or JIT languages, which are too complicated for a hobby-OS or a microkernel which has severe performance problems. Porting the C library is complicated enough, so you don't want to implement interpreted languages before starting with your OS. And, besides, the environment that interprets and compiles will need to be coded in C/C++ anyway, with all the problems that those languages have when run in flat address spaces.