Will Intel remove 16 bit support in future CPUs?
category: general [glöplog]
I think this could have pro and cons. I' m not sure how much space would be saved on the cpu/die (when removing only 16 bit stuff, or creating a 64 bit only cpu) and how and how it affects the speed of code executions.
Tiny (DOS) intros will certainly continue to run in emulators / virtual machines. I really love all this amazing 32 to 256 byte intro shit. XD
Here is a link to the intel website:
Envisioning a Simplified Intel Architecture
Tiny (DOS) intros will certainly continue to run in emulators / virtual machines. I really love all this amazing 32 to 256 byte intro shit. XD
Here is a link to the intel website:
Envisioning a Simplified Intel Architecture
this reminded me to check if the A20 gate is still present in modern cpus:
https://en.wikipedia.org/wiki/A20_line#A20_gate
i am really surprised that it was killed ~10 years ago ;-)
https://en.wikipedia.org/wiki/A20_line#A20_gate
i am really surprised that it was killed ~10 years ago ;-)
Apart from reducing QA surface I wonder how much removing the 16 bit support would actually help..
I asked myself this question a few years ago. Now it seems that companies are actually taking this step - and removing "legacy" from the CPUs.
A few days ago, ARM also announced a new generation with the "Total Compute Solutions 2023", which is probably based on 64 bit only; and 32 bit pigtails are cut off.
I think I read something that says it could be 10-20% more power and efficiency. Can't find the link and data/table right now.
A few days ago, ARM also announced a new generation with the "Total Compute Solutions 2023", which is probably based on 64 bit only; and 32 bit pigtails are cut off.
I think I read something that says it could be 10-20% more power and efficiency. Can't find the link and data/table right now.
finally this will move native dos intros (slowly) into the oldschool section.
mind you there is still emulation, no software will cease to run all of a sudden.
mind you there is still emulation, no software will cease to run all of a sudden.
Sorry for my focus on the A20 gate, but the removal by Intel has its 10 years anniversary now. Link goes to german it news: https://www.heise.de/hintergrund/10-Jahre-Abschied-vom-beruechtigten-A20-Gate-in-Intel-CPUs-9095042.html
Removing 32 bit support would make much more sense, savings wise..
It seems like they want to remove parts of it, and that 32-bit operating systems won't run?
If you check the link to the intel website, they are talking about "How Would a 64-Bit Mode-Only Architecture Work?". Seems they are thinking to remove 16 and 32 bit support.
Some more info:
Intel is paving the way for a transition that removes legacy 32-bit and 16-bit support.
Intel publishes a white paper on x86S, a 64-bit only architecture
Intel is paving the way for a transition that removes legacy 32-bit and 16-bit support.
Intel publishes a white paper on x86S, a 64-bit only architecture
Quote:
Benefits of x64-bit only architecture according to Intel:
- 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.
hold on to your 486s
Quote:
If you check the link to the intel website, they are talking about "How Would a 64-Bit Mode-Only Architecture Work?". Seems they are thinking to remove 16 and 32 bit support.
I did, and it seems like they're keeping support for 32-bit applications in 64-bit mode, so what I meant is that they probably have to keep a lot of the transistors dedicated to 32-bit support for now.
There are too many applications still using 32-bit mode so they would not get away with removing 32-bit application support anytime soon.
And I totally understand why they would want to remove legacy features - they add special cases they need to work with in their designs and they also increase the attack surface. E.g. the A20 gate was used for bypassing the secret boot ROM on the original XBox.
And I totally understand why they would want to remove legacy features - they add special cases they need to work with in their designs and they also increase the attack surface. E.g. the A20 gate was used for bypassing the secret boot ROM on the original XBox.
Basically this removes the fact that the CPU boots in 16 bit mode and the BIOS has to do various things to enable 64bit mode. It also removes some features that no OS except maybe OS/2 ever used.
It may not simplify the CPU part so much, but it will simplify the MMU by removing support for 32bit physical addresses, and probably a few other things. I guess several instructions that exist only in supervisor mode (used only by kernel and drivers, not by applications) can also be removed, and these are the ones where you can expect 32bit support to be a very special case where there is a lot of logic to remove.
It may not simplify the CPU part so much, but it will simplify the MMU by removing support for 32bit physical addresses, and probably a few other things. I guess several instructions that exist only in supervisor mode (used only by kernel and drivers, not by applications) can also be removed, and these are the ones where you can expect 32bit support to be a very special case where there is a lot of logic to remove.
Exactly as PulkoMandy said. They're keeping the things that are simple (32-bit ring 3 support) and removing the things that are nasty (all the special cases in the MMU and TLBs for various obsolete page table and segment descriptor formats and lookup schemes). That will cut some logic and a lot of verification time.
I'm surprised to see "rep outs" go though, as that shouldn't be too hard to keep; on the other hand, no current HW uses PIO any more, so it's probably the right call to kill it along with the other legacy stuff.
I'm surprised to see "rep outs" go though, as that shouldn't be too hard to keep; on the other hand, no current HW uses PIO any more, so it's probably the right call to kill it along with the other legacy stuff.
16-bit? Oh, you mean 8-bit.
Or rather, the most wannabe 8-bit CPU without ever being one. Nobody coded Assembler, who cares. Everything clunky and 1970s, who cares. 50 years later, let's kill the clunky.