Intel Wants to KILL 32-bit Mode in its CPUs - X86-S Explained
Vložit
- čas přidán 1. 06. 2023
- Get 25% off Blinkist Annual premium! Start your 7-day free trial by clicking here: blinkist.com/garyexplains | Intel has published a paper describing a simplified version of the x86_64 instruction set architecture, called x86-s. In the proposal, Intel lays out plans to remove 16-bit and 32-bit legacy modes from x86_64 and only support 64-bit long mode. Goodbye 8086 real mode, goodbye 386 protected mode!
---
Let Me Explain T-shirt: teespring.com/gary-explains-l...
Twitter: / garyexplains
Instagram: / garyexplains
#garyexplains
Get 25% off Blinkist Annual premium! Start your 7-day free trial by clicking here: blinkist.com/garyexplains
THIS IS A HUGE OVERSTEP OF POWER AND CONTROL. AS AN AMERICAN I AM LOOSING SECURITY BY HANDING IT OVER TO INTEL.
ITS ALL COMPROMISED , SAVE YOURSELf.
What's been holding Intel back was its spying hidden instruction sets. Which were running below level zero. If they get over having to maintain that it will be able to really rebuild the architecture and make it more energy efficient. Otherwise there's a huge concern whether they'll be around at all.
6:36 "You can't get a 64-bit version of Windows 11, for example." Yes, you can.
Great video, as always! Thanks, Blinkist, for sponsoring!
@@JohnPMiller I mean just , but still... all in all..... one will be made to replace it , because its structural integrity and privacy is deeply compromised #1, and 2. the win 11 UI is just bleh...
And I base that on Full control settings , and ease of hidden panels,bg programs past user control ... etc..... as if you were an OS engineer , not a user or company .....
I just pump the 32 bit support because of developer accessibility .
Yes great video thank you !
You said you would have a link to explaining real vs virtual memory‽
And if they do away with 16&32bit
How is os\2 supposed to work then? (Half kidding)
Fun fact: because of the 16 bit modes, you can still boot into MS-DOS and/or FreeDOS on any modern x86 CPU. Well, if I'm not mistaken you still need to have legacy BIOS boot, the MBR kind and the keyboard has to be PS/2 or emulated, not stricly on USB. At least for MS-DOS. FreeDOS I think has a few extra compatibility features.
You'd only run DOS on an emulator or legacy pc anyway wouldn't you?
You definitely can use a USB keyboard with FreeDOS, I have done so myself. But the other requirements are correct yes, CSM mode on in the firmware, MBR partition and so on.
Lol yeah, you can still find people on CZcams doing silly things like using an i9 and an ISA adapter for a Sound Blaster booting modern machines into DOS to play old games. Although interesting, I just prefer to keep a few semi-collectable old machines around for when I want a retro experience.
Yep
@@marcusk7855 i’ve run FreeDOS to flash RAID cards with different bios. probably could do it in uefi shell some how
One interesting point that Gary didn't make is the reason that AMD was the one to come out with 64-bit x86 extensions instead of Intel, and that this is not the first time Intel tried to leave compatibility modes (and maybe x86 clone companies?) behind. At the time, Intel and HP were pushing their VLIW (corrected thanks to James Duncan below) architecture called Itanium as a 64-bit solution and letting their x86 lineup remain at 32-bit for the consumer market, and Microsoft created a version of windows to support the new Itanium 64 bit architecture for Intel & HP. Around the same time, AMD (who had an x86 license but NOT an Itanium license) had no choice but to continue to develop x86 or face irrelevancy. Thus, the AMD-64 architecture was born, backwards compatibility was preserved, and Microsoft built the 64-bit version of Windows for this x86 64-bit standard. When the Itanium stagnated, and AMD64 gained traction in the market as a compatible alternative, Intel had to do something, and was rumored to be coming up with their own extensions to x86. To add insult to injury (if I remember correctly) after the costs of building an Itanium version, Microsoft was reluctant to build *another* x86-64 version for Intel's proposed 64 bit x86 competitor, forcing Intel to make their processors compatible with the AMD-64 instructions for 64-bit x86 moving forwards.
I think that removing backwards compatibility mode, so long as the ability to use older programs in emulation was sufficient, probably will be good for the average consumer. If it isn't though, be sure that AMD will be there again to capitalize on what Intel leaves on the table. If it makes sense, great...we all get better faster machines. If it doesn't make sense, someone will be there to "retain compatibility because people want it" and gain market share because of it. Either way, it'll work out.
He did, and Itanium was not RISC. You should seed the video again, review the history of Itanium again and understand what the architecture was about and why it did not perform.
But Itanium wasn't a perfect solution either. If I remember correctly its ABI had very long instructions, which made it difficult to optimize programs at compile time and the following I'm not sure, but I think it included hardware x86 emulation, but so slow and inefficient that it was not worth it.
I clearly said it was AMD that invented 64-bit x86.
Itanium was a VLIW architecture. Also, in fairness to Intel, the consumer space at the time really could not use more than a 32-bit address space.
Yeah, he did.
Lots of people are talking about compatibility with older operating systems but that is already a lost battle:
With the likes of UEFI, GPT disks and secure boot, it is already impossible to boot the really old OSes (like DOS) in 16bit mode. With the management engine on modern CPUs, it is also often impossible to flash custom firmware and get around this.
At this point, the legacy boot modes are already mostly useless. Management engine was the thing to complain about as that actually prevents you from running unsigned firmware
Exactly 👍
Most Systems support Legacy-Boot and most OSes doesnt support UEFI boot by default
"it is already impossible to boot the really old OSes (like DOS) in 16bit mode." No it's not (not really to be precise). Just a examples :
czcams.com/video/bS9hiSwL1KY/video.html
czcams.com/video/YAHbJ_S2a6E/video.html
czcams.com/video/WcRtNnd8lFs/video.html
@@edelzocker8169Some people forget that this exists.
Fun fact: I worked in a small software house just before the millenium. They used clipper as software for their video customers. We were in panic, because at this time the motherboard producers wanted to switch to modern standards with only USB and no PS2 or serial connection. We used normal desktop computers as billing points.
yeah ... theat brings back memories from the old days ... remembers me of the great "nantucket tools 2" library😆
bro you can get a Ryzen 7950x motherboard TODAY with a PS/2 port I don't know what you're talking about.
@@ssl3546 and with COM header too, and you need a card with a ribbon to connect to it
ARM Cortex X3 core .............. 19% higher IPC than AMD Zen 4 ........... 17% higher IPC than Intel Raptor Lake
New Cortex X4 ....................... 33% higher IPC than AMD Zen 4 ........... 24% higher IPC than Intel Raptor Lake
How x86-S is gonna help with that?
I'd expect x86-S will get rid of variable instruction length encoding (to solve polynomial explosion problem due to need to decode multiple instructions in parallel). RISC has 32-bit fixed instruction length so CPU knows exactly where all instructions start. x86 instruction can have 1 byte up to 15 bytes so 10th instruction could begin at 10th byte up to 136th byte = 126 possibilities. This is the worst pain of x86 which hurts CPU efficiency and apparently it's not being solved? Crazy.
Fun fact: Windows executables still have MS-DOS header at the beginning of the file! 😀
Ahoy, thanks for the video. Remember, this is bleeding edge stuff. In the Real World (R) such as banking and industry 16 bits isn't even dead as some of it still runs on that (especially industrial machines). Before I retired in 2011 I was still servicing 32 bit Warpserver computers, mostly at banks, investment firms and retail stores. I suspect I'll be fertilizer before this comes to full fruition. Cheers, daveyb
Doesn't surprise me since coding is the same. A lot of times you deal with code that is probably nearly as old as the developers charged with maintaining it. COBOL is a great example of old code that is still used, to my understanding a lot more so in banking and finance. It wouldn't surprise me if 32-bit was still a thing when I'm retired.
I don't think they use the same processors. Mainframe apps are powered and run in a mainframe server. The terminal that you use to interface with the mainframe app doesn't need to run in 16 bits. 32 bit support will still remain.
If some industries still want to keep their 8 and 16 bit programs, maybe they deserve to go the way of the dodo. They had 30 years to update their programs and chose not to? Just pure laziness.
@@triadwarfare Say that to every university that needs to keep their legacy machines running because they simply can't afford to upgrade. When I studied chemical engineering my university still had analysis machines from the early 80's, and were desperate to keep them in running order because a new one would set them back close to 1million €
I'm sure my nutrition quality will better than yours.
@@AFnord Saying €1 million is meaningless if it cost €2 million to maintain the old gear.
I think main reason are "soon" expiring patents for start "edition" x86_64, new patents for x86_64-S will block enter in the market for other players. All legacy instruction are probably for decades executed by micro-code.
Doubtful since x86 and x86_64 are both out of patent already. x86 by a stupid margin, and x64 by I think 4 years. There is a ton of newer tech made in the last 20 years that's covered by patent without needing this though(both intel and AMD have a bunch of extensions that you couldn't add).
Still, there's nothing stopping a person from making a processor right now, and there's plenty enough that make older ones for industrial use, just nobody that wants to put in the billions to only potentially compete with the desktop/server market in the years it would take to try and catch up. Even VIA with a golden ticket to compete in the market has all but given up.
I think that's bullshit, all computers we have now use 64bit, 32 bit is almost useless and taking out of the chip will free space so they can make better chips, those relying in 32 but can just buy older chips
You don’t understand. 64-bit code can use 32-bit instructions and 16 bit instructions. There are advantages such as smaller instruction and data size which means 64-bit compilers use large numbers of 32 bit instructions.
I've heard people say that it might make internal validation easier for intel.
@@soylentgreenb And those (probably) can be used under 64-bit compatibility mode.
X86-S simply means you won't be able to BOOT into 8/16/32-bit OS (DOS/Windows), that usually utilized those instructions natively.
Think of it like this : A driver packing stuff onto a bike or into a lorry.
It doesn't matter what you want to pack, a lorry can take whatever a bike can (I assume here, Intel won't "cut out" 16-bit/32-bit instructions support).
And from what I understood from the video, Intel simply removes the part where our driver has to hop on a bike, to get to his lorry at the start of work day. X86-S means lorry is parked outside driver's house, and no bike is needed. It has nothing to do with what you can pack into bika or lorry (again, I hope).
This probably won't affect most end users, but it's kind a big news in the computer history.
Btw I didn't know that cpu nowadays still boot into 16-bit mode first and then transit to 64-bit. Great content as always!😄
You'd be surprised at what sort of apps turn out to be still 32bit
Even Steam is 32bit, for example
EDIT: Okay, if compatibility mode stays, this won't be a problem
@@AceWing905 The only reason steam is 32-bit on windows is because they don't need to upgrade it. It's been 64-bit on Mac for years and works just fine. The day 32-bit support is dropped you'll see steam release a 64-bit client.
@@LunaticEdit Makes sense
But I misunderstood originally anyway
If compatibility mode stays, then Steam can remain 32bit
1. SMM is currently entered in 16 bit real mode. Very first thing it does - switch to 32 bit protected mode and further to 64 bit long mode.
2. If UEFI boot is used, CPU enters BIOS in 16 bit real mode, BIOS switches to 32 bit mode, then 64 bit mode and only then loads OS. 16 bit mode is used once.
3. If legacy boot is used (MBR+CSM) then BIOS enters 16 bit mode before loading OS. MS DOS or outher 16 bit OS can be used or OS loader can switch back to 32 and 64 bit mode.
@@volodumurkalunyak4651 UEFI Class 3 removes CSM. Intel wanted to enforce UEFI Class 3.
Starting from the 10th Gen Intel Core, Intel no longer provides Legacy Video BIOS for the iGPU (Intel Graphics Technology).
My AMD X670E motherboard still has CSM and AMD RDNA2 IGP still has Legacy Video BIOS for CSM.
Just considering that BIOSes and UEFI firmware will have to change as will all hypervisors which will offer virtualization of and on these new processors. It's going to be a long, long transition.
UEFI Class 3 has removed CSM.
Starting from the 10th Gen Intel Core, Intel no longer provides Legacy Video BIOS for the iGPU (Intel Graphics Technology).
I'm not sure it will.
- BIOS is essentially gone with the current generations
- UEFIs are all specific to the current hardware IE new CPUs will roll out at the same time as new, compatible UEFIs that use these features
- Hypervisors shouldn't need any more attention than operating systems and all relevant, modern ones are probably already operating in 64bit
@@jameshogge but will this affect the ability of Windows to run 32-bit apps?
@@DanTheMan827 The table around 3 minutes showed that Long Mode/Compatibility Mode will still exist. 64-bit Windows will continue to run 32-bit applications.
@@DanTheMan827 No a 64-bit OS still can run 32-bit applications and a 64-bit hypervisor still can host 32-bit OSes through normal comp mode.
The only thing that will change is that the CPU can no longer boot into 32-bit OS natively or boot into a 32-bit hypervisor.
So absolutely irrelevant considering Win11 doesnt even have a 32-bit edition anymore and anyone who would want to operate a 32-bit hypervisor with modern hardware should maybe see a doctor anyway.
Slightly off topic, but How much physical space does the 32-bit stuff take up on their CPU chips?
probably not as much as the complexity it adds
If a highway had 32 lanes, 32 cars could pass at once. Imagine 64 cars passed at once.u need twice the space. Unless they make the road and car smaller (transistor size)
It does take quite a physical space and complexity inside a instruction decoder. Speaking about whole CPU - very little. Mocern CPU's are very wide out-of order superscalar monsters with huge caches, reducing instruction decoder yields small benefit.
Apple managed to turn those small benefit into quite a larger one by also redesigning caches and outher parts ot CPU core
yeah i think it is less about the space that would be freed rather than some architectural optimization paths of x64 that will open up. but surely some "transistors can be removed" and replaed with something more "useful".
They compile the instructions anyway. It takes extra RAM and dedicated instruction hardware to compile it faster.
The question is really whether it makes sense to switch then to X86-S vs just going straight for ARM. The only reason Intel is still big is because of Windows with its own 16-and-32-bit mode software still commonly in use (eg. Excel) which has things like OLE and DDE from Windows 3.0 that many, many software sold today still haven't changed (unlike Mac, nobody is forcing them to modernize).
Are you running software today on Windows 10 that uses 16-bit OLE stuff from Windows 3?
1. 32 bit program support on 64 bit OS is not removed yet in x86S.
2. 16bit program support is not present on any 64bit Microsoft OS.
3. 32 bit OS and legacy boot suppport (that relies on 16 bit support) are getting removed in x86S
Change any software???
Anything but OS itself can stay the same.
As long as I can still play 16bit games from that awkward period where it's too new for DOS and too old for 32-bit windows, I'm happy.
You'd probably be better off using something like DOSBox or 86box for that kind of stuff tbh - modern computers aren't going to have really good soundblaster compat
I have a question. Will it be possible to install 16/32 bit operating systems on a virtual machine (VirtualBox, VMware...) on host with X86-S processors? Will I need to disable Intel VT or AMD-V in a virtual machine to run a 16/32 bit system?
No, because VM-Software will emulate the hardware BUT it will run slower
i think x86-s its a good idea without a hidden business agenda. would ease the design of x86-64 cpus from scratch (not that there are a lot of new ground-up designs now)
It's an Intel initiative, not AMD's.
Gary, what are the benefits of a 64 bit only cpu? Would it allow them to save on die size by removing some transistors? And with modern SSD based systems booting pretty fast, would this make a noticeable difference in boot times?
I'd say yes to the first question and probably no to the second. The CPU only spends a couple seconds in 16bit mode before it switches to 64bit. I doubt it will be noticible without a stopwatch.
Removing 16 bit and 32 bit modes (except mode for 32 bit program on 64 bit OS) does simplify instruction decoder. That could help reach higher clock speeds at the same voltage and power.
@@volodumurkalunyak4651 Not only that, it simplifies and streamlines the rest of the processor too as there is less "state" to keep track off.
Quite a bit of the old stuff will be handled by microcode and/or extra internal op-code space (read: more wires), so an increase in overal power-efficiency can also be expected.
Beyond the direct impact, I suspect it allows more design freedom too as certain backward-compatibly issues are no longer things to be worried about and thus won't hold back use of better design options. They must have run into those in the past all the time, figuring out something clever, but never get to use it due to that compatibility demand.
It would allow them to do new marketing.
it's not boot times it's wasting less silicon to run old instructions Supporting all the modes means you must have hardware (or instruction translation of some kind) dedicated to that.
i have a dell latitude 5510 i686 64 bit cpu and i tried to create a 64 bit linux os in virtualbox and i got an error message saying this is not a supported kernel i have to use a 32 bit linux os 😢
what are the advantages/features of all modes?
interesting how much die space this will save for x86 CPUs? how much energy is wasted? Intel wants to catch up with others and going to redesign their architecture.
Intel certainly knows how to create heat; some efficiency gains may be realized, but I doubt they'll get the power/performance levels of AMD.
I think it will be very insignificant. It's just cleanup and a few miliseconds faster boot time
I had a similar question as @4olovik, is this freeing up die real estate? Also, what implication does this have on the other extensions over the years such as MMX and SSE? Seems like the benefits should be more than jumping through a few legacy boot modes as that’s been a technique honed over nearly 40 years!
As always, love the content Gary!
Every bit matter!
Even 2 sents save will give millions to Intel!
Almost nothing. This isn't about die savings, but more about engineering resources. Every time they 'add' something they have to do a ton of engineering work to ensure all the legacy crap still works. It's a waste of time considering all that legacy crap isn't being used by anyone anymore.
I used to work for a GPU company. To this day there are legacy blocks in modern GPUs that aren't even enabled in software anymore. Things like video encoders for codecs not used anymore. They remain on the die simply because the engineering effort to remove them is not worth it. The people who wrote that code are LONG gone (either literally, or have moved on to other projects and don't remember what they wrote 20 years ago) so trying to requalify everything after removing those things, and fixing the multitude of unintended consequences just isn't worth it. It was easier to just remove driver support for this hardware, so they don't have to SUPPORT it anymore, and leave it wasting a very small amount of die space.
Intel obviously has figured the time has come where the effort in removing this legacy crap is actually worth doing. Most of that is because they've never deprecated this legacy crap, they still need to ensure it all works, even though nobody uses it.
I am all for the x86-S mode implementation!
Apple dropped the 16-bit & 32-bit modes years ago!
Is this going to have any performance benefits? Is this related to reducing/simplifying the instruction set in any way?
Eliminating parts of the instruction set that aren't needed simplifies the design and could indirectly lead to small benefits, but I wouldn't expect the change alone to result in a direct benefit. It's cleaning up.
It's a step in the right direction but they should really bite the bullet and introduce a new encoding, drop the segment registers, legacy floating point instructions and registers, legacy descriptor tables, obsolete instructions, etc. ARM did this with ARM64 - which is essentially a completely new instruction set compared to 32-bit ARM.
That's probably because legacy 32bit ARM products are still being produced... once AMD / Intel go full X64, there will be no more 32bit processors for legacy products... but then I suppose they could just make legacy products....
One of the key selling points of x86 is backwards compatibility. The only reason why such an ugly architecture survived for 45 years is the massive amount of software written for it. The x64 architecture itself is already 20 years old, and still contains a lot (although not all) of the obsolete stuff in the architecture. Changing it would completely render every x86 software inoperable. It still does a good job at removing a lot of unused stuff and cleaning up the opcode table.
The x86 PC is, unlike Android or Apple's ecosystems, open (thank goodness). You can't just come and say: every software will have to update or it won't work on the next CPUs. Something like this can definitely work on an ARM ecosystem, where the device's manufacturer controls what applications can be installed. But not on x86.
Both 32 and 64-bit modes are gonna be stuck with us for quite a long time. But this new x86S pretty much does what you point out. Segment registers are not used, descriptor tables are also not used with the new FRED event delivery. Legacy floating point instructions are used quite a lot actually (even 64-bit, because they implement the 80-bit type in hardware) so they can't be removed.
What does this mean for tools like memtest?
I think it's a matter of the golden handcuffs of upward compatibility.
What you’re asking for is called “RISC-V”.
As a proof of concept they really need to make the x64-S as they envision it, but emulate everything they want to take out in software, see what works, and what breaks when you take it away.
Though how that will work with VirtualBox i don't know, as VirtualBox uses a different permission mode and runs on the hardware, thus it might mean having to emulate the older 16/32bit instructions for older OSes.
Another option might be if they include a JIT recompiler that will recompile 16/32bit code into the native 64bit and then just run it there, much like PCSX and certain chips in Japan did.
As far as I understand, the CPU is still able to execute old code without any fundamental changes in 64bit long mode, maybe less efficient (no memory advantages), though. I think most of these changes only get rid of a lot of legacy stuff, that doesn't make sense anymore and/or isn't used at all for decades. I would assume, that these changes are not that fundamental for CPU or board manufacturers to implement. This is more a "behind the scenes" kind of cleanup operation that won't really change much for the user.
@@cfusername Yeah, i can see a number of instructions that work the same regardless (pretends it's 32bit when ti's just 64bit because it makes no difference on 32bit code), unless you wanted to do interesting bswap opcodes to have extra register spaces.
The only real issues i can think of would be the immediates used, which can be in [memory] locations, or to a value applied to a register. It comes down to how much it can reduce complexity, to which saves spaces, which makes it faster or lets them put more cores on one die.
Though under the hood with microcode, likely the raw CPU's aren't changing much and are already 64bit and just the microcode is relied on; So being able to rip out a basically-unneeded layer would let them save room on more important new instructions.
Did Intel talk about how much die space might be saved (if any) from cutting out the older modes?
Intel P-cores are huge when compared to AMD Zen 4.
I doubt there will be anything meaningful at all. These are all relatively small changes to control structures (whereas the big die space consumers are memory structures & accelerators that have many duplicates of the same logic).
@@jameshogge Wrong. If not looking at caches which will simplify the instruction decoders significantly.
@@jameshoggeyeah I disagree with that assertion. I bet there’s a decent amount of die space built to preserve the old structures, just like when I’m working on 10 year old software, there’s significant amounts of old code that’s superseded by new code but the old is kept to keep customer X running.
@@ericnewton5720 I see two problems with this:
1. When comparing to software, the things that are large in hardware are small and the things that are small in hardware are large. Take, for example, a section of code with lots of control flow. Each conditional can be broken down into a few gates and you end up with a relatively small logic circuit. Now allocate an array. This is just one line of code but in hardware you have to generate an enormous structure to back it up.
The big consumers of die space inside processor cores are largely all memory structures: the branch predictor, the reorder buffer, L1 caches, micro-op caches, the TLBs, the register files, load and store queues.
2. The legacy modes can largely reuse the same hardware. They offer subsets of the 64bit ISA. In the decoder, this may manifest itself as a single control signal that masks off the 64bit instructions when not in that mode. Given that x86 uses variable width instructions, it might not even require that.
I think the biggest changes are likely to be around address generation for loads/stores as these legacy modes come with different addressing modes. These are, however, a couple of small functional units and all of the large memory structures will either be unused or used but unchanged. Intel/AMD would be mad to build in separate copies of them.
So what does that mean in practice? I understand I cannot run 32-bit Linux (let alone MSDOS) on such a new system anymore (not that I would want to), but does this have any impact on running legacy software under 64-bit Windows? Or is that running in an emulator already today?
32-bit software works as it did before on a 64-bit OS.
This has been a long time coming with Intel already getting rid of UEFI CSM on their boards. No CSM means no MBR booting, so really only modern 64bit Operating system can be used.
The worst part is, if it does result in cheaper CPUs, and ones that might even run better, all consumers will get is either the same performance at the same price, or more expensive for the same performance.
I remember that when Samsung removed chargers from phone boxes, they decreased the price for one generation of phones by like $100 to decrease backlash, only to raise it back to normal a year later. We might see a similar thing.
It wont result in cheaper CPUs, the 32bit intructions are small, really small in sillicon size, that you wont get any benefit in performance, cooling or price
It depends on a lot of things. I built my 4790k rig for about $1k without a GPU.
For $1k now I can get a 12900k rig and $1k has less value now than it did several years ago.
I also have a $1k laptop with an OLED screen (13th gen i7 and a 3050) that can out render or at least match my desktop 4790k and 1080.
That's a full laptop for $1200 after tax beating a desktop from 7 or 8 years ago that cost over $2k, 1k for the PC, $700 for the 1080, $300 for the monitor, and another $150 for kb&m.
@@leonro Apple did the same by using the environment as justification to get more money out of you.
06:37 I guess you wanted to say you can't get 32-bit version of Win-11.
🤪 Ooops!
@@GaryExplains I have question what advantage shall we get from it? will it result in more performance, stability, more transisters or cache on CPU?
So with x86-s cpu won't be able to boot dos even in vm unless we disable hardware acceleration for virtualization..
That's all great, but what about my games from the prehistoric times will they run, or do I now have to run a VM.
I am quite sure that technically UEFI is only 32 / 64 bits at boot.. however a lot of UEFIs also include or a built upon traditional BIOS'.. partly for compatibility and partly because you can easily get hold of these from certain companies (eg AMI) rather than to have to make one from scratch.. Also I'm quite sure you can write a boot loader for a UEFI that supports 16-bit.. but initially it will have to execute in 32-bit mode.. On another note I think that the discontinued Itanium range by Intel were 64bit only. Also just a simple mistake @6:30 you state that "you can't get a 64-bit version of windows 11" 😛!
Well, it was probably a slip up. Gary likely meant you can't get a 32bit version of Windows 11, but you also technically can't get a 64bit version of Windows 11 because it's the only version. Semantics... But you're right... I think he actually meant to say 32bit Windows 11.
@@alcorza3567 I realise that that's why I said it (the slip up) was a simple mistake.. the other stuff was my focus
Unfortunately they are still keeping the GDT, LDT, IDT and segment registers since they can't get rid of that without breaking existing operating systems.
Is there any benefit for this shift?
Any performance uplift or security improvements?
You save space in CPU and also makes it cheaper and simpler!
Aka you CPU has now parts than don´t do anything, unless you use older programs.
People whp use legasy programs needs this feature, but everyone else could use the same space to something more usefull. Either make CPU smaller or add new features at the same space!
@@haukikannel people using legacy programs will be able to use a virtual machine to keep using them
Is compatibility can be achieved via emulation? So we'll be able to run programs and enjoy them for many years to come?
Will they use this opportunity to simplify/reduce the need for "intel management engine" ? If they are going 64bit only, and therefore changing the boot environment, there are lots of long standing security objections to IME, and it would be great if they could clean that up so that people who can have a more assured platform to build on.
it's not entirely 64bit only... it's just that the OS is 64bit which is already true if you account for UEFI... because you can't run win32 on a UEFI64 and everything is UEFI64 (there's no dual UEFI32/64)... just legacy bios (which will disappear for real with x86-S machines)
Intel ME and AMD PSP are probably left unmodified there. Those do already use separate management cores anyway.
The IME and PSP are intelligence agency backdoors and won't be removed.
The only problem I can think of is that people learning assembly for the first time even now often start with 32-bit before working up to 64-bit. That said, few people even try 16-bit assembly anymore, so I guess skipping straight to 64-bit may be reasonable.
you can easily use a virtual machine for these things
People around me still have to start with 8 bit or 16 bit as part of curriculum 💀
you can still run 32bit programs just fine... on 64bit OSes nothing really changed... and when developing OSes people tend to use VMs which still would work just fine to boot 32bit OSes
@@dsa1979 x86S removes support of running 16 bit code even inside a VM.
To get an introduction to what assembly is like, any mode will do IMO.
For normal application code, the concept of registers, the type of operations and addressing modes is in the end what it is about.
Getting to learn how memory works, what the access costs are, how dependencies and predictability impact performance is what develops later.
Most will never have to code in assembly, but it can be a useful skill to figure out what a compiler is doing and where things do not go as intended and why.
Will they still support things like vb6 as we have applications in vb6 which are only 33bit
Did you understand the part in the video about the 32-bit compatibility submode of 64-but long mode?
@Gary Explains I didn't at the time as there was two parts to the 32 bit subject and I wasnt sure where the application fell. I read other reply and figured it out thanks for the reply I really appreciate it.
So what happens to DOS and DosBox for retro gaming?
Nothing
I'm all for it. CPU design/manufacture has reached a point where generational differences in power efficiency and speed come from how well every last nanometer of the die is used.
The opposition is mainly "but what about..." exceptions -- like old industrial machines, retro uses, etc. -- that ignore just how niche and small those markets are, and that the majority of those can already be handled with VMs and emulators/translation layers, and even more such programs will be created during any transition period with even greater compatibility and performance.
Other manufacturers will still license and produce 386 and 486 cores for those markets just as they still produce Z80s and 6502s nearly 50 years on.
It makes no sense unless they do full instruction set refactoring.
I would tend to agree with Intel getting rid of everything except 64-bit computing, but also they need to greatly reduce the amount of supported instruction sets. The support reduces efficiency, reduces speed, adds heat (waste) and adds cost.
AMD dropped 3DNow with Bulldozer, FMA4 and XOP with Zen.
Intel tigerlake supports some avx512 instruction sets
Intel feels ARM breathing down their neck, with a more streamlined, legacy-free ISA.
they didnt removed 32bit... they just removed 32bit OS capabilities that were not used... because UEFI forced the OS to be 64bit already... (if UEFI were forced to be both 32/64) then they would not had done that
>The support reduces efficiency, reduces speed, adds heat (waste) and adds cost.
Huh?! X86S, as written by Intel, is only reducing the firmware & UEFI size. It's irrelevant to how a CPU actually runs on an OS. You're about 50 levels too deep in abstraction. This is a very low-level, arguably invisible change.
will you be able to still play dos games, in dosbox?
Yes
I don't assume it will affect dos-box or anything like that would it?
No. DosBox emulation Code are CPU independent. Special optimized routines for x86-64 and ARM exists for DOS protected mode games, but those routines was designed to use user mode 32 and 64-bit registers, then no problem at all.
Well by gutting compatability modes they'll probably be able to go further and faster with the x86 platform. All this legacy stuff can hold back performance for sure. Do I think it's a good idea? It depends. The potential sounds nice but it comes at a cost. Sometimes legacy stuff is just better. But if you wanted to build something from scratch that didn't include any older software than perhaps it's the way to go
Good overview of the paper but I would have liked it more if you spent some more time explaining the real world implications of such a move.
I don't think there are any real world implications for 99.5% of people.
I would expect some gains in terms of recovering die space from the 16-bit modes. But it’s probably not a lot because you could fit hundreds of 386s onto a modern processor chip.
They can probably reduce gate delays just a tiny bit too since the obsolete modes don’t need to be checked for.
I suppose it’s in the paper but was hoping to hear a bit about that here.
There is still a lot of Windows code which is 32-bit only. For example, Microsoft Visual Studio itself only moved to 64-bit within the last year or two.
And 32-bit apps will continue to work.
If someone has old 16 bits applications, they can run in emulators, like DosBox. I do not worry for the software.
For old hardware that are external to the computer, they communicate with the computer by a serial or parallel cable. There are still motherboards that support those connectors, or one may use a USB adaptor.
For old cards plugged directly on the motherboard... the motherboards themselves already lost the oldest connectors. If one uses an old motherboard, it cannot support newer processors anyway.
I do not really see a scenario where the 16bits legacy mode is mission critical for anyone. If someone has an example, I would be happy to learn it.
why x86S ? Is it better than arm or risc-v ? Has it more power effeciency ?
Do you use x86 now or something else?
link to the paper?
As I say in the video just Google x86-s or "Envisioning a Simplified Intel Architecture".
How have they not made this transition like 10 years ago!?
Intel wanted to launch a platform called itanium. Ever heard of it?
Ever wondered why x64 is also called AMD64?
@@sarowie That's a dumb answer - do you want to delete your response? There's a difference to making a CPU so different it requires compilers and OS's to perform magic tricks to make code work at speed with no compatibility of anything before it versus something that's more of an evolutionary step on the x86 road. And yes I'm aware of the history of AMD64.
I loved playing supertux almost 20 years ago on my laptop having a 32 bit pentium III coppermine core.
Supertux isn't the problem, it can be recompiled for 64 Bit. The problem is software that requires something like a 16/32 Bit Windows 9x/Me inside a VM.
@@OpenGL4ever it's not that. Supertux is a matured game so it's easy to port onto anything.
My point was 32 bit was faster than 64 bit back then and packages were few, libraries were a nightmare and hardware support was mature for 32 bit. 64 bit used more memory... Most of us had few. I had 384 MB of memory.
Everything that 64 bit was had an overhead to it. Now all this is moot.
@@pamus6242 I disagree. When 64 Bit was available in 2003, 1 GB of memory was already common and i had 2 GB in my PC. Less than 512 MB of memory is a 1999 thing. That was 4 years before the first 64 bit x86 CPU came out.
And when Intel released its 64 Bit Core2Duo i bought it with cheap 8 GB.
Also, 64 bit is not slower than 32 bit, but faster because it has more registers and this speeds up program execution. With function calls, for example, more values can be placed in the registers for parameter transfers instead of having to save them slowly via the stack and thus slow main memory.
Another reason why 64-bit binaries were practically faster is because the base of 64-bit CPUs all had SSE2 support as the lowest common denominator and you could develop and ship the software for it. While with 32-bit you still had to consider CPUs that did not support SSE2. Thus your common denominator was much worse.
@@OpenGL4ever
Most people could not afford computers back then !! Let alone have an internet connection. Most people on budgets weren't buying Intel. AMD was that underdog that got the job done.
People bought older stock because it was cheaper than buying new and the displacement of new hardware versus old was much longer unless nowadays where it just makes sense to buy newer gen hardware than older. It wasn't until the phenom I came out that 64 bit became etched permanently because those chips were cheap and phenom II's were cheaper!! Couple this with the advent of DDR3 being more than affordable, 32 bit computing would pretty much have been dead by 2010.
ALso most people could not afford RAM and it wasn't needed unlike today.
This isn't 64 bit being better than 32 bit, the point being most people preferred 32 bit over 64 bit because one was either using a 32 bit chip or the RAM requirement for running in 64 bit mode for a 64 bit chip was 4GB.
There is nothing great about 32 bit, its done.
@@pamus6242 We are talking about 2003, not 1990!
In 2003 everyone had a PC, including one ore more older PC as second computer.
Where do you live? In a third world country?
We were not talking about price. We where talking about RAM.
And BTW, in 2005 BF2 was released and it required at least 1 GB o RAM.
Would DOSBox and other emulators still work?
Yes
What will the advantage be of a X86-S for the users? Faster boot?
Cores can get slightly smaller. And more cores or more L3 cache can fit in the same amount of space, maybe?
Faster instruction decoders and thus faster CPUs. Less shenaningas in system software.
x86 emulation has gotten so far that I say it's very doable using software
Every x86 CPU runs as RISC inside => so we have HW x86 emulation in since 1994 AMD K5.
This SW emulation of old x86 on new x86 CPU using CISC-to-RISC HW translation sound kind of over-engineered. Why not running just RISC in a first place and save a lot of transistors, energy and effort?
Probably a good thing in the long run, though the lack of real mode or virtual 8086 mode might cause some compatibility issues for some software. Especially in industrial and business settings, very often, if the software works, they don't replace it and will go to great lengths to keep hardware around to run it. Pure 32 bit protected mode stuff might still run fine, but other stuff, not so much and hardware that will run it natively will eventually become hard to find and hideously expensive.
Though by the time this tech hits the market, it should be possible to emulate a 32 bit x86 chip well enough to run any of those mission critical legacy apps well enough to get the job done. It's probably doable now, maybe not for software made at the very end of the 32 bit era but for a lot of the older stuff various companies are running at least. The instruction set isn't completely different, so virtualization for at least parts of it might be viable. Someone would make a Rosetta style compatibility layer.
So all in all, assuming Intel works on a Rosetta style application to cover any mission critical applications that won't play nice in compatibility mode, this should be a good change.
> Especially in industrial and business settings
Let's not forget government. 8)
Various levels of Japanese government are currently wrangling with ridding themselves of floppy disks at long last.
they will upgrade/change the hardware most likely. Also this X86S architecture doesn't imply that intel will stop producing X86 (current one) CPUs ... if they can sold those CPUs, probably it will do it. but anyway if the business has to buy new x86 (not S) CPUs, at that point they could buy X86s CPUs and install a virtual software to run X86 legacy architecture... if they are not willing to modernize their software. But i think most likely they should do also to use probably something like ARM CPUs instead that are more energy efficient, therefore reducing costs in the long run and payback the investment of modernizing the infrastructure (considering those machine are working kinda 24/7)
Would having a single legacy core on the chip fix this? Do the efficiency cores support these modes?
@@jampipe3137
By that point, you just give them purpose made cpus that run 16 and 32bit made on older mature fabs
@@Demopans5990 There's AMD, VIA and DM&P Electronics (continues SiS' Vortex86 line). X86S in an Intel initiative to enforce UEFI Class 3.
To classify somewhat the long mode does not support real mode or virtual-86 mode so old DOS programs cannot be run on it. It does support 16-bit protected mode but Microsoft has chosen not to provide that support in Windows.
So basically that means just that you must use a 64 bit OS. For normal end users nothing changes, they just need to have a copy of the Windows that supports the new CPU.
And/or a Linux beyond a certain level where the bootmanager supports it
I would wish you link your own videos you mention in the description
It makes sense. All software can simply be recompiled and will work fine.
If the software is so old that the code is lost, then just keep using pre-2024 machines, or reverse the code and re-compile it.
Maintaining backwards portability for 40 year old code is like a 40 year old still sleeping with his Teddy Bear.
Recompile is not always an option; but emulation is. 286, 386, 486 ... emulation is a solved problem.
Only actively maintained or open source software can be recompiled. Which is actually the minority.
32 bit is not terrible, it just has a 4 GB memory limit. I also don't miss being stuck with 4 GB file size limits.
4gb file size has nothing to do with it. It's the FAT32 format......
@@TheHighborn This is incorrect. Both have a 4GB limit. This is because 2^32 is approximately 4 billion
It’s terrible because it adds a lot of overhead to the ISA, making it use more gates meaning it is less performance per watt.
@@jameshogge No, that's because of design limitations of old Windows versions. Other operating systems never had a 4GB file size limit on 32-bit architectures because they used more than 32 bits to represent file sizes and offsets.
You can surely operate a 32 bit system with more than 4gb of ram, Linux already does that, but every program opened can only use 4gb of available memory
Will it still be able to run 32-bit OSes in VMs?
Yes
@@GaryExplains wrong. I read a x86S Intel document and it says: "Guest is always in long mode"
My big question is how this would affect old games or programs once you have the modern 64 bit os booted and try to play an old 16 bit dos game in dos box. I would be very concerned if that would be something that's not going to work anymore, or if it would require a large amount of work to overcome the lack of the old 16bit mode and its instruction set.
If those old programs can still be booted using our current solutions without massive reworks then I will go back to worrying about what MS is planning on doing with TPM requirements.
If you can play them in DOSbox on 64-bit Win 10 or 11 now, then nothing will change.
DosBox implements a old x86 CPU within a software routine. Since DosBox runs on many non-x86 processors and x86-s don't Change anything.
I feel that for integrated circuitry designers this feels like having to maintain an old delphi/pascal runtime while running everything else in modern C++ or Rust.
ahhh, yes. delphi - back when desktop software actually worked well.
@@PaulSpades yeah, back when automatic updates didn't exist as excuse to ship bad code lol
@@MarcosScheeren Honestly, there's way better tech, tooling and documentation in VB6, Borland 2005 and Lazarus than whatever passes for a GUI kit wrapping MFC these days. Modern devs just got a bad deal, and you don't know what it's like to have a stable platform and well written libraries that make sense (and don't change every other week).
I still use Delphi V5 and V7 - and it's still awesome!
This from the people who resisted 64 bit as long as possible. I'm sure they have an ulterior motive, I just don't know what it is yet.
I believes Microsoft already knew about this hence they said only x64 Windows going forward back then.
Pleased to be introduced to your channel -- and here I thought at first blush you were just another blathering brit hahaha... Great info on this topic -- thanks!
that was a bit of a sneaky promotion segment xD had me thinking for a second, wasit what does this have to do with the video xD good video though gary as always
While the proposed transition might seem like a simplification at first glance, it's important to recognize that such changes could potentially introduce new issues and failure modes to the ecosystem. This is not merely resistance to change, but a pragmatic outlook informed by our previous experiences.
Take, for example, the transition from BIOS to EFI. Although EFI has offered some improvements like faster boot times, support for larger drives, and a more sophisticated interface, it's also been accompanied by a variety of challenges. EFI's larger codebase increased the attack surface, making systems more vulnerable to security threats. There were also complexities and compatibility issues that arose, often requiring users to navigate additional steps like disabling Secure Boot during the installation of certain operating systems.
While some of these issues have been mitigated over time, it's worth noting that they led to complications and headaches for many users, IT professionals, and developers. The simplicity and intuitive nature of BIOS, which allowed users to configure their systems quickly and easily, was lost in some respects in the move to EFI.
Yes, technological progress is often accompanied by disruption, but it's crucial to ensure the proposed advancements indeed provide tangible benefits that outweigh the potential drawbacks. It's about finding a balance between encouraging innovation and maintaining stability and usability in our computing environment.
Furthermore, the assertion that x86's days are numbered isn't intended to dismiss potential improvements but rather to bring awareness to the shifting landscape of computing architecture. With ARM gaining prominence in various sectors, it might be prudent to consider where our resources and efforts are most effectively utilized.
In conclusion, the key to successful innovation lies in careful analysis and cautious implementation. We should strive for a thoughtful approach that minimizes disruption, maximizes benefits, and ensures the continuity of the ecosystem while embracing inevitable changes.
Hello, ChatGPT.
@@leisti It's just a tool the ideas are still mine.
Didn't Intel already remove the 16-bit instruction set (the hardware) a couple of years ago?
I don't know. You can still run 16 bit apps in 32 bit windows 10, so I don't think they have. I haven't tried it in windows 11.
No. Microsoft only removed compatibility for it from 64-bit Windows.
IIRC this will also get rid of a bunch of deprecated instructions.
It's a good Idea, with virtualization there's no longer need to have those instructions for niche use cases
I think you mean emulation.
@@lawrencemanning no he mean virtualization like VT-X (which still can be used to have 16bit and 32bit OS VMs)
@@gregorimacarioharbs5715 The hardware still needs to support the instructions to use VTX, and if 32-bit was removed this would not be available.
@@lawrencemanning Imagine the speed of the old 16/32-bit applications. And the power consumption.
I'm just waiting to see how world of warcraft wotlk performs. But they aren't going to offer an emulation layer, are they?
@@gregorimacarioharbs5715 x86S removes 16 bit modes and some 32 bit modes entierly. Virtualisation will NOT bring those back except VMM takes a job emulating those.
Very ironic, being as AMD started 64 bit . Beware - you may be running 32 bit apps without realizing it. 👍👍👍
32-bit apps will still work. Did you watch the video?
no, AMD did not start 64 bit. For some reason we now consider x64/AMD64 to be obvious; but it is not.
Intel thought Itanium; Microsoft went along.
There was Sun Sparc CPUs and sun solaris.
There was apple with PowerPC CPUs.
Now, the end of x86/x64 is coming; either by ARM (look around - you will have more ARM cpus in your house then Intel) or what ever intel and amd agree.
RISC V will also play a role. If you doubt that: Ever heard of Acorn RISC Machines in some early home computers?
@@sarowie Nice to know - thanx. I still believe AMD brought 64bit to the global market before anyone else.
In Microsoft windows 3.1, you can install win32s subsystem, it allows you run certain 32bit program , and win95/98/ME can run true 32bit program, but the OS still didn't treat CLI(clear interrupt flag) instruction as dangerous instruction, and allows all program to execute it, I don't know what's the difference between windows NT and windows 98, maybe program runs in win98 are all ring 0 priviledge level, so it allows you to run CLI and did not trigger any protection fault....
So would it be better or worse?
Better
I'm for it. I've been on the 64-bit bandwagon since the 90s (SGIs, etc.) ;)
I think this may have a transition period... they might keep everything for the consumer market while transitioning the server/HEDT to this, then bring the consumer products in after some time. But, I'm all for flipping the switch.
It would be nice if they still included some sort of emulation mode to run old applications.
That is what they've been doing. They're talking about stopping doing it, as Arm already has done..
@@BruceHoult no emulation is different. There can be an emulator running the application
@Robert Lawrence I think the confusion here is the word emulation. At an application level there are of course emulators like DOSbox or whatever, but there is also some hardware level emulation that the CPU can do. For example there is a Virtual 8086 mode in the 386 (and later) allows the execution of real mode applications while the processor is running protected mode. It is a hardware virtualization/emulation technique
@@GaryExplains thanks for clarification. I hope there will still be ways to run old legacy software even If it means via emulation software only to simulate the legacy modes. I'm sure if it gets abandoned that there will be some smart people out there willing to make them.
32bit applications still run fine (and natively... just the OS is forced to be 64bit... which is basically already the case with UEFI being 64bit only... so x86-s is basically removing what can't even be used)... just for 16bit programs that emulation (or VM capabilities) will need to be used, (which does not matter, because 16bit programs are faster that even with 1/10 of speed they still run faster than javascript stuff on browsers hehe)
Given new machines only UEFI and dropped legacy support, makes sense for future x64 CPUs anyway.
Didn't really get into the benefits and drawbacks of the changes..but oh well.
There aren't any drawbacks, if there were Intel wouldn't do it. As for benefits, they are as I describe, just removing stuff from 1978 that isn't used any more. I thought I covered all that, but oh well.
If this makes the chips cheaper, then I’m for it. I have a feeling Intel will find a way to release “64 bit only!” Cpu for a premium somehow
ARM and apple silicon running 64bit only is because they have a unique (niche) position in the industry of being able to force recompiles on software, whereas Intel has been the king of backwards compat. This became less needed during the hard push to hardware level virtualization. Imo, preserving 32bit as a chipper will be important going forward but only accessed in a virtualized container most likely.
I doubt that it will be a premium. More like this means they don't have to support and validate those other modes. That's a stupid amount of testing for something almost no one using modern processors uses. Plus, imagine if there was a massive bug in there. Lots of egg on Intel's face if they didn't do enough validation!
They really want to compete with ARM. Removing all the old stuff will basically turn X86-S in a kind of risk engine (I know that the microcode engine on X86 is already some kind of "augmented risk engine" as the instructions are broken into a risk dispatch (if we can call Power risk). We also know that ARM was blessed by Apple's aggressive stance in that sense. I know Apple should not be mentioned, but one year before Android they moved to 64 bit ARM (A7)
Apple moved to 64-bit using AArch64 as designed by Arm and Arm launched its AArch64 64-bit CPUs a year before Apple, however yes, on Android the actual chip makers were slower to jump over.
is there any convincing Advantage of 64 other than supporting more ram?!
there's some tricks with increased address space as well, but for the rest... for each advantage there's an disvantage that can easily nullify it... so it does have double amount of registers... but they increase code, and with proper optimization they end not being really necessary, also with "context switch" (when you run more programs at same time... more data have to be copied for 64bit... which makes such stuff heavier).... (btw 32bit x86 and... 32bit windows/linux can use up to 64gb of ram, altough on windows (non server versions) that was disabled... and never enabled by them again (only trough patches) i have a win7-32bit with 8gb of ram (the limit is my motherboard hehe)
Can this affect Windows games on Linux? Many of them works in 32-bit mode under wine
Did you watch the video?
@@GaryExplains I did but did not catch that. They promise no concern to the user but the concern not about the promise it about how it would be in real.
I guess the point is that an x86-s PC running Linux can still execute 32-bit code in the compatibly submode of long mode. That feature isn't OS dependent.
@@GaryExplains i hope so
This is a great idea for people like me that have lots of boards/cpu's that will age like fine wine due to that 32bit compatibility for people wanting to have access to older software which will be around for at least 8 years after the newer cpus stop supporting... Welp looks like my 8700k, 9900k, and 4 i5 10th gen cpus along with 3 ryzen 3000 systems are being time capsuled for value gain :D
Most likely it will be the next Itanium. Unless they offer some way to run old software on it.
What do you mean by "old software"? An OS like XP? Or a 16-bit DOS program?
@@GaryExplains Well, old software is any proprietary software still in use, that needs specific hardware to run.
In most parts of the world companies, governments, etc. use specialized software written locally, that has embedded specifics of the local law. The most common such software would be one that calculates taxes. Such software is often left without any support, as rich foreign companies tend to buy any local software company, usually not for their business, but for their software teams. So most of the specialized software is quite old. Probably 80% of it requires Windows XP, 95 or DOS compatibility. There are emulators, Dosbox can emulate DOS environment, but it is made so people can play old games. And even then it is not 100% compatible, as some games run poorly. And you'd be lucky if your old software will run without any problems, as whoever makes such emulators didn't consider compatibility with it.
Perhaps that's not a problem in G7, but Intel sells not insignificant part of its products outside of G7.
@@forbidden-cyrillic-handle But that is a different problem, you can't run XP or Windows 95 successfully on a modern PC either (no drivers). So X86-S changes nothing about this. I don't believe that you are buying new Intel processors today and running Windows 95 on them.
@@GaryExplains Writting a driver for XP, is usually easier than rewriting the old software that has no source code. You only need to know how to write such a driver and you can look at the code of any open source project that works with this device.
I think this title is a bit clickbaity. They appear to be killing off 16-bit compatibility. I... guess that's ok. I mean, the major use case for 16-bit compatibility on 64-bit systems is DOS gaming... but, uh... my dad still has a copy of AutoCAD 14 kicking around, and based on the fact it works on 32-bit Windows and not 64-bit, it has SOME ties to 16-bit libraries. As far as why he doesn't upgrade... he paid full price for 14 when he got it. He owns the license to that copy. He's not going to pay for another, let alone rent one through some idiotic subscription model.
Now, if/when intel DOES kill off 32-bit compatibility... the edge x86 has had for the longest time will suddenly just... evaporate. It will be gone. x86-32 and x86-16 software will require emulation to run. And CPU emulation is slow. Whatever architecture can emulate it fastest will be preferred for those operations. And, of course, the use case for 32-bit lies primarily in gaming. You do NOT want to get gamers pissed off. Bad idea.
CPU emulation is slow, except when the CPU you are running on is SO much faster than the CPU being emulated it won't make a like of difference. By the time you've got a 64bit only x86 CPU on your desk, it's CPU emulation speed will be far faster than any current x86 CPU that supports 16bit.
And that's ignoring that current machines won't evaporate. I am typing this on an 11 year old machine, it works perfectly for my purposes.
This is a non issue.
Does this mean that the Playstation 5 at startup works in 16-bit mode?
Yes.
Maybe, there could be a microcontroller with full i386 compatibility, 64MB Ram and ISA-Bus? I don,t need to run DOS on my new computer.
By killing off 16-bit and 32-bit applications, you kill backwards compatibility along with it. Bad idea.
Why? You don't have to buy 2024 products. Just buy old stuff.
Interesting comment. What 16-bit applications are you using?
They still have a compatibility mode (check the top half of, say, 3:25 ). But even without it, emulators, especially for 16bit should be able to do the job for maintaining compatibility.
16 bit applications probably run fine on a 16 MHz or slower processor. You can fully emulate a 16 MHz 8086 or '286 at full speed in Javascript. Probably in Python for that matter. For my meagre accounting needs (think 1 invoice per month to be PDFd and emailed ) I still use an accounting program I bought in 1991. It is written for the M68000 Mac and is laid out for a 512x342 screen (you can drag the windows bigger). These days I can run it in an emulator on modern Arm (or Intel) Mac, on a PC, on Linux on x86, arm, RISC-V, or in a web browser. At many times the original speed.
I think emulation has come so far and most backwards compatibility can be done through software
Will this move the needle for overall power consumption? There are so many other things that x86 does these days that are odd, such as compensating for lack of registers by translating instructions to use internal registers, that I wonder if that is where the real power savings would come from? That would seem to be a far harder thing to change -- see the failure of Itanium.
I don't think it will change power consumption at all. Did you watch the video?
@@GaryExplains I did watch the video which is why I was wondering how this moves the needle for Intel, or even where it moves the needle.
It just removes legacy stuff from 1978 that no one uses anymore .
My question is what is the benefit of this removal to the customers? The system boots are going to get faster or what could be the real tangible advantages to a day to day user?
Better security for one.
Lower power consumption
I support this, because Intel in terms of chip design has always favored complexity
I had heard back in the days of, like, the 486 that there was so much backward compatibility in them that if you installed an older floppy drive, they could still boot and run CP/M. I wonder if that was still true in the Pentium or Core eras, and if so, when it became untrue. Probably not for CPU reasons, I'd bet - probably from changes of disk interfaces.
In 2020 Intel firmware dropped support for running 16-bit/32-bit or non-UEFI operating systems natively. But it may have stopped working before then.
486 had pretty poor backwards compatibility actually. I really do not remember the reason but there was definitely operating system software that only went as far as the 386.
@@ssl3546 I don't think that is true.
If the compatibility modes are still there, what is all that cruft still there for, then? 🤨
I have two questions. How much will this reduce the cost of production? Will the CPU need less clock cycles per instruction? If the answers are very little and no then what is the point? There is another question 256 bit processors. There have been specialist ones for decades. Will migrating to 256 bit mean we go through all this malarky again?
Before 256 bit comes 128 bit and there isn't a need for 128 bit at the moment. Most CPUs now support 128 bit SIMD instructions.
I find it odd that Intel went with 5-level page tables with 9 bits per level and 12 bits to index into the 4KiB page yielding 57 bits of virtual addressing instead of 4-level page tables 12 bits per level and 15 bits to index into the 32KiB page yielding 63 bits of virtual addressing
4KB pages need to finally die, large pages should become the default both in sw and hw.
2mb pages should be the standard.
I wish Intel would come out with this now as I am just about ready to build a new system and it would be nice to ditch the legacy junk.
why aren't there 128 bit cpus? is the 64 bit architecture the last station?
Why would you need 128-bit CPUs? There are of course 128-bit SIMD instructions.
With all its backward compability, operating modes x86 got so complicated that there is a hidden Minix clone OS called Management Engine (ME) is needed to coordinate the processor startup. So the unixoid Minix OS is the most popular operating system of all. So ist that ME needed after cleaning up all the historic remains of the 8 /16 bit era ?
But in computer history it is not unusual needing a small system to startup a big one. The first computer i used was a Digital Equipment pdp10 36 bit "mainframe". For managing, startup and communication a small pdp 11 (18 bit) was used. I think similar architectures appear with IBM hosts or even supercomputers.
Intel ME runs on it's own management cores anyway. It barely uses main cores at all (turns those ON at system bootup and only manages DVFS, thermal throttling and somethings like that afterwards). Only thing to change in Intel ME - how to turn main cores ON (reset vector - now 64 bit, also prepeare page tables, that all may be done already). SMM (system management mode, it's code is part of BIOS) - some changes (first thing it does - goes from 16 bit mode to 32bit protected mode and further into 64bit long mode) also requires changes (those could also be made now with some silicon changes)
There is specialty software on windows that was made in the 90's or even the late 80's that is still used to this day because nobody ever bothered to make a replacement, because the original still works just fine. e.g. Winjammer Professional (1992) which is still the king of piano roll MIDI data editors and tons of other one off programs written by some random person on usenet for one highly specialized purpose.
And that software from the 80s and 90s can be run in hardware from the 80s and 90s. Just go out and buy 3 second hand PCs for $50 each and you are set for life.
@@GaryExplains its way more convenient to run all your software on one machine. i cant imagine the pain of having invested in the macintosh ecosystem for that reason.
It would be great to understand what benefits this actually would have over the regular x86 ISA. Would it mean less die area has to be spent on hardware supporting classic x86 ISA? Would security be drastically improved? Would boot times be faster and more secure? Would OSes be less complex and faster due to dropping that same legacy baggage? How would Windows and Linux be affected by this? Would there be performance benefits in applications? What would the effects on memory management mean? What would Intel and AMD do with the extra die space on silicon? Would there be a benefit in power efficiency (especially seeing as we know x86 is behind RISC in the power game)?
The benefits are mainly just removing legacy stuff from 1978 that no one uses any more. Basically technical debit.
@@GaryExplains absolutely, I get that, but I'd be interested to know based on my previous questions what (if any) benefits there would be by removing this legacy stuff, otherwise why remove it if not to get some advantage from it.
As I said the main benefit is removing stuff from 1978 that isn't used any more. Fixing the technical debit. The answer to all your questions are all negative. OSes won't be less complex or faster. There won't be any performance benefits, etc.
x86 less power game? in mobile segment yes? the M1 excel very well? but hardcore supecomputer? x86 still ahead from RISC based CPU
@Mich X Not quite, the second fastest supercomputer in the world, the Fugaku, uses Arm cores, it was the fastest during 2022. The 5th and 6th place computers use POWER9.
Although 16-bit support was in cpu's up to recent, Microsoft stopped supporting running ms-dos programs from win7 onwards. So there is anyway not really away one can run 16 bit code on pc anyway and one needs to use dosbox if you want to.
So it makes sense that intel wants to remove the legacy stuff from their processors.
MS didnt stopped running ms-dos program from win7... it stopped on 64bit windows... win7-32bit that i'm using still have supported NTVDM... win10-32bit still have supported NTVDM
Which microsoft dropped support for windows 10 32bit with the may 2020 update, though the whole os goes end of life on Oct 25th 2025. Which windows 11 is 64bit only.
@@DanB-0 no they didnt.... they just said that OEM version (that come installed) can't be 32bit. but you can still buy and upgrade win10 32bit to latest... but yes win11 does not have a 32bit version... so windows 10 32bit will be supported till the end of win10 life in oct 2025.
This would be an actual regression on perfomance per watt for 32bit apps.
Wrong. 32 bit app support is still there. 32 bit support is going to be removed from x86S - only way to use 32 bit app will be under 64 bit OS as everyone already does
So, Weird Al's words aren't out-of date? "In a 32-bit world you're a 2-bit loser." He meant Operand size all along, not address space.
"John, why are destroying all the 32-bit technical manuals?"
"Hey, the industry is going pure 64-bit, and I don't do things halfway."
"But someone might still need that information."
"I DON'T DO THINGS HALFWAY"
So long as the 32bits apps still work on the OSes, the only problems come from the old 16bits apps and their preservation, but it's a problem that was already there since there is no support for them in 64bits mode anyway.
Thankfully, we can emulate old 16bits systems rather easily, (as long as there IS an emulator for the one we want to run, that is) so unless we insist on running them natively, there shouldn't be any real problem.
Yeah, like for example using 32-bit DOSBOX emulator to run GW-BASIC which is a 16-bit interpreter
What will happen to my 32 bit retro games? For example will I still be able to play the original GTA San Andreas from 2004 or will I have to buy some modernized version that is compiled for 64 bit? I mean it would feel stupid to buy again what I already paid for plus let's be honest not all games will be re-compiled for 64 bit.
Did you watch the video because I explained about the 32-bit submode of 64-bit long mode.
So it can still run 32-Bit apps?
Yes
@@GaryExplains Good to know. Thanks for clarifying.