This time it'll definitely catch on - Intel publishes spec for 64bit only x86

[BachChain]

Summary

Under the slogan of "Envisioning a Simplified Intel Architecture", Intel has published a draft specification for "X86-S". This variant of the venerable x86 CPU ISA would strip out all of the legacy 16 and 32 bit components as well as several obsolete features, leaving only x86_64.

 

Quotes

Quote

Certain legacy modes have little utility in modern operating systems besides bootstrapping the CPU into the 64-bit mode. It is worth asking the question, “Could these seldom used elements of the architecture be removed to simplify a 64-bit mode-only architecture?”

Quote

What Would Be the Benefits of a 64-bit Mode-Only Architecture?

A 64-bit mode-only architecture removes some older appendages of the architecture, reducing the overall complexity of the software and hardware architecture. By exploring a 64-bit mode-only architecture, other changes that are aligned with modern software deployment could be made. These changes include:
 

• Using the simplified segmentation model of 64-bit for segmentation support for 32-bit applications, matching what modern operating systems already use.
• Removing ring 1 and 2 (which are unused by modern software) and obsolete segmentation features like gates.
• Removing 16-bit addressing support.
• Eliminating support for ring 3 I/O port accesses.
• Eliminating string port I/O, which supported an obsolete CPU-driven I/O model.
• Limiting local interrupt controller (APIC) use to X2APIC and remove legacy 8259 support.
• Removing some unused operating system mode bits.

 

My thoughts

I think clearing cruft is an admirable goal. It's kinda crazy that a Ryzen 7000 or Raptor Lake processor still has to act like 8086 when it turns on. Less architecture also means less places for bugs and vulnerabilities to live.

 

Sources

https://www.phoronix.com/news/Intel-X86-S-64-bit-Only

https://www.intel.com/content/www/us/en/developer/articles/technical/envisioning-future-simplified-architecture.html

[SorryBella]

26 minutes ago, BachChain said:

Intel has published a draft specification for "X86-S". This variant of the venerable x86 CPU ISA would strip out all of the legacy 16 and 32 bit components as well as several obsolete features, leaving only x86_64.

Wouldnt that still be so much more than proper RISC like ARM and RISC-V?

[AlTech]

16 minutes ago, SorryClaire said:

Wouldnt that still be so much more than proper RISC like ARM and RISC-V?

Well yes cos x86 and x86-64 are CISC ISAs. RISC is separate and is a different thing.

[05032-Mendicant-Bias]

The success of X86 was because of the backward compatibility, I'm not sold on dropping some compatibility.

By this point I think you'd better off with a new more efficient ISA without all the baggage.

[LAwLz]

This is probably a very good idea for servers, but because of how the Windows ecosystem looks I doubt this will fly for most average consumers. 

 

Too much proprietary software that companies aren't incentived to update, and in many cases can't because they rely on other proprietary software that nobody is incentived to update. 

 

 

Meanwhile, Arm processors for general processing are basically 64bit only these days. 

It took Arm less than 10 years to go from their first 64bit processor to having all their Cortex series be 64bit only. 

[Sauron]

I mean... if only. You'd lose compatibility with some old stuff but realistically that could all be made to work anyway through some software compatibility layer, after all if something is that old it probably doesn't matter if it executes a little inefficiently.

[BachChain]

7 minutes ago, LAwLz said:

This is probably a very good idea for servers, but because of how the Windows ecosystem looks I doubt this will fly for most average consumers. 

 

Too much proprietary software that companies aren't incentived to update, and in many cases can't because they rely on other proprietary software that nobody is incentived to update. 

This does not affect the ability to run 32 bit usermode binaries. Even now, those run while the CPU is in 64 bit mode. This should only affect firmware and OS kernel level stuff.

[starsmine]

38 minutes ago, 05032-Mendicant-Bias said:

The success of X86 was because of the backward compatibility, I'm not sold on dropping some compatibility.

By this point I think you'd better off with a new more efficient ISA without all the baggage.

I cant imagine it would lose backward compatibility. Can still just emulate those 32bit/16bit commands without having a hardware level path for them, but it would be unable to boot into OS that are not 64bit

 

[LAwLz]

2 hours ago, BachChain said:

This does not affect the ability to run 32 bit usermode binaries. Even now, those run while the CPU is in 64 bit mode. This should only affect firmware and OS kernel level stuff.

Are you sure about that? I'd love to read up on it if you have a source.

 

Perhaps you are thinking of WOW64? WOW64 does not translate 32-bit instructions to 64-bit instructions. It handles switching your CPU into 32-bit compatibility mode for specific processes (at least on x86 processors, on Itanium it does actually translate the CPU instructions). WOW64 also does other things necessary to keep 32-bit compatibility when running Windows in 64-bit mode, for example redirect registry calls since the registry hiararcy looks different in the 64-bit version, but none of the things WOW64 does actually alter the code of the applications, which is why it has next to no performance penalty.

 

 

 

If 32-bit applications could run in 64-bit mode then I don't see why we'd need WOW64 in Windows to begin with. Or at the very least we shouldn't need WOW64cpu.dll.

Quote

Wow64Cpu.dll: Manages the 32-bit CPU context of each running thread inside Wow64, and provides processor architecture-specific support for switching CPU mode from 32bit to 64-bit and vice versa.

 

[BachChain]

10 minutes ago, LAwLz said:

Are you sure about that? I'd love to read up on it if you have a source.

Straight from the document

Quote

3.3 Removal of 16-Bit and 32-Bit Protected Mode
16-bit and 32-bit protected mode are not supported anymore and cannot be entered. The CPU
always operates in long mode. The 32-bit submode of Intel64 (compatibility mode) still exists. An
attempt to load a descriptor into CS that has CS.L==0 and CS.D==0 will generate a #GP(sel)
exception.

 

[LAwLz]

51 minutes ago, BachChain said:

Straight from the document

Oh okay, so they wouldn't remove the 32-bit compatibility mode from the CPU.

I thought Intel was proposing dropping 32-bit support but after reading some of the document linked in one of the pages, it makes more sense.

 

They are basically only proposing dropping some features that aren't even used these days in 64-bit operating systems. All the important stuff (like 32-bit compatibility mode) is still there.

[Forbidden Wafer]

5 hours ago, Sauron said:

I mean... if only. You'd lose compatibility with some old stuff but realistically that could all be made to work anyway through some software compatibility layer, after all if something is that old it probably doesn't matter if it executes a little inefficiently.

Yeah, like the ARM one on Windows. Basically transpiling low level 8/16/32 bit instructions to 64bit and masking things away. Doesn't seem that hard to do. 

[Kisai]

9 hours ago, BachChain said:

Summary

Under the slogan of "Envisioning a Simplified Intel Architecture", Intel has published a draft specification for "X86-S". This variant of the venerable x86 CPU ISA would strip out all of the legacy 16 and 32 bit components as well as several obsolete features, leaving only x86_64.

 

Quotes

 

My thoughts

I think clearing cruft is an admirable goal. It's kinda crazy that a Ryzen 7000 or Raptor Lake processor still has to act like 8086 when it turns on. Less architecture also means less places for bugs and vulnerabilities to live.

 

Sources

https://www.phoronix.com/news/Intel-X86-S-64-bit-Only

https://www.intel.com/content/www/us/en/developer/articles/technical/envisioning-future-simplified-architecture.html

The only reason they're doing this now is because of Windows 11 no longer shipping a 32-bit OS.

 

This has SOME consequences (like Windows XP won't be able to be booted, even in a VM), but also various OS's like Linux and FreeBSD will also have some issues with their bootloaders, since they won't be able to ship a bootloader that can run on both 32-bit and 64-bit OS's.

 

Not that it's a huge loss. If you are running 32-bit linux or freebsd, it's because your OS is 10+ years old.

 

edit: Oh! There is ONE piece of hardware that might be impacted. If you are using PS/2 KB+Mouse. Since the the APIC is removing 8259 support (which is IRQ0-9) that means IRQ1 is no longer available for it. PS/2 mice are on IRQ 12.

 

At worst, that means KVM's, and "remote hands" might be impacted if they are using the front-panel PS2+VGA.

[leadeater]

7 hours ago, LAwLz said:

This is probably a very good idea for servers

Personally I'd say the opposite, only because lots of Windows servers have to run garbage software with super ancient code and Windows module usage... sighhhh

 

[starsmine]

1 hour ago, Kisai said:

The only reason they're doing this now is because of Windows 11 no longer shipping a 32-bit OS.

 

This has SOME consequences (like Windows XP won't be able to be booted, even in a VM), but also various OS's like Linux and FreeBSD will also have some issues with their bootloaders, since they won't be able to ship a bootloader that can run on both 32-bit and 64-bit OS's.

 

Not that it's a huge loss. If you are running 32-bit linux or freebsd, it's because your OS is 10+ years old.

 

edit: Oh! There is ONE piece of hardware that might be impacted. If you are using PS/2 KB+Mouse. Since the the APIC is removing 8259 support (which is IRQ0-9) that means IRQ1 is no longer available for it. PS/2 mice are on IRQ 12.

 

At worst, that means KVM's, and "remote hands" might be impacted if they are using the front-panel PS2+VGA.

wait what? why would a VM of an older OS not boot, you are not leaving the hypervisor and going into a boot mode.

[leadeater]

38 minutes ago, starsmine said:

wait what? why would a VM of an older OS not boot, you are not leaving the hypervisor and going into a boot mode.

It won't if it's a Type 1 Hypervisor but it will if it's Type 2.

 

Quote

A Type 1 hypervisor runs directly on the underlying computer's physical hardware, interacting directly with its CPU, memory, and physical storage. For this reason, Type 1 hypervisors are also referred to as bare-metal hypervisors.

 

Quote

There are two main hypervisor types, referred to as “Type 1” (or “bare metal”) and “Type 2” (or “hosted”). A type 1 hypervisor acts like a lightweight operating system and runs directly on the host’s hardware, while a type 2 hypervisor runs as a software layer on an operating system, like other computer programs. 

 

A VM on a Type 1 hypervisor does get presented a virtual CPU but it's hardware capabilities are directly exposed so if the CPU can't boot the OS then the VM will not boot either.

[Kisai]

32 minutes ago, starsmine said:

wait what? why would a VM of an older OS not boot, you are not leaving the hypervisor and going into a boot mode.

Leadeater beat me to it, but a bare-metal hypervisor (type 1) wouldn't be able to.

 

It's probably not a big deal unless you are trying to virtualize a mix of 64-bit and 32-bit OS's. Like in many cases when a company migrates hardware, they just copy the OS image straight over, even if it's Windows server 2003 (XP), Redhat or FreeBSD that has been running 32-bit kernels since 4.x 

 

Like the amount of issues I see for servers is greater than that I see for end-user consumers who will likely never run into the problem if they buy the computer with Windows 11 with those chips. From a security point of view it makes more sense to remove the instructions on consumer systems so that a theoretical piece of malware can't insert itself as a hypervisor on the computer. 

[Taf the Ghost]

I do appreciate Intel trying again. If it's a patent just coming out now, it's for a product in 2 years. We'll see how it goes.

 

Also, here's a link for COBOL programmers on Indeed. https://www.indeed.com/q-Cobol-jobs.html?vjk=4e08e4d68c34f0e7 And Fortran: https://www.indeed.com/q-Fortran-jobs.html?vjk=cd6ad242790b3b67

 

Obviously, there are constantly updated revisions to the backend system languages. But this is going to be a multi-decade phase out.

 

 

[WolframaticAlpha]

2 hours ago, Kisai said:

Windows server 2003 (XP), Redhat or FreeBSD that has been running 32-bit kernels since 4.x 

Most of these OSes have gone EOL, so I doubt if there will be many clients using them. As for the legacy users, I suspect, intel won't necessarily stop selling some of their x86-64 processors to major legacy users.

[wanderingfool2]

8 hours ago, WolframaticAlpha said:

Most of these OSes have gone EOL, so I doubt if there will be many clients using them. As for the legacy users, I suspect, intel won't necessarily stop selling some of their x86-64 processors to major legacy users.

You'd be surprised at how many there can be...but admittedly chips are quick enough that you probably could just emulate the hardware well enough and it would work.

 

Some reasons why some older OS stuff sticks around, software written for it exists and there isn't a budget to get it updated because the software was multi-million dollars in development.  The software was written for specific old hardware (in specialized cases) and the communication was proprietary or just old

 

A good example of this is the Expo-line in Vancouver.  Parts of it uses old systems, simply because it was the standard at the time and the cost to replace the system would be likely in the ten's if not hundreds of millions.

 

Another example, at my first place of work we had an old server that I actually did run in an emulator inside a VM.  The software had newer version out, but they had changed the licensing fee from perpetual to yearly license/user.  Switching to the now yearly/user license was economically unfeasible as we had all users using that server, so we would have to dramatically change who got access hurting business or pay an exorbitant amount (probably to the point of having to let a few people go).

[bcredeur97]

I could maybe see this causing a problem for things like cash registers that still run DOS (iirc I think Home Depot of all places still uses those in a lot of areas). 

They could always make specialty hardware for these people though.

 

I wonder if this would pose a problem for FreeDOS bootdisks for those rare times you need to flash firmware on something (mainboard, gpu, etc.)

[Kisai]

1 hour ago, bcredeur97 said:

I could maybe see this causing a problem for things like cash registers that still run DOS (iirc I think Home Depot of all places still uses those in a lot of areas). 

You'd be amazed how often you see IBM POS systems show up in places.  

 

Again, I don't see consumer systems being impacted. Like many of these POS systems are PC104-type SBC units anyway, so they are proprietary hardware of a specific kind. The current version is PCIe 5.0, but has been consistent since 2011 despite being released in 1992. It kinda has a life-span about twice as long as a Intel desktop funny enough. But again, it's full of proprietary stuff in a much worse way than the desktop PC.

 

Those computers running the Target/Walmart/BestBuy checkouts are not that different from self-checkouts themselves.

 

[Vishera]

1 hour ago, bcredeur97 said:

I wonder if this would pose a problem for FreeDOS bootdisks for those rare times you need to flash firmware on something (mainboard, gpu, etc.)

As far as i know FreeDOS is 16-bit, so it probably won't work.

[Eviljuche]

Nothing really scary, since all the 16/32 bit x86 stuff would work anyway via the binary translation module (or how Intel calls it in their own article, VMX), it's just that it would be a bit more resourceful. Transmeta did that in Crusoe lineup, Intel did that themselves in Itanium series, and MCST is doing it now in Elbruses with relative success.

[manikyath]

if this finally scrapes some bloat out of x86 architecture and makes it at least a bit better in competing with RISC (that's both ARM and RISC-V) power efficiency, i'm all down for a half-emulated legacy 'support-ish' for 32-bit stuff. make it an OS_level software layer for all i care.

 

i was recently delving into some docs for microcontrollers, and apparently the powerful stuff is all moving towards RISC-V because it's cheap to implement, and apparently gets 250MHz out of milliwatts.