• Welcome to TechPowerUp Forums, Guest! Please check out our forum guidelines for info related to our community.
  • The forums have been upgraded with support for dark mode. By default it will follow the setting on your system/browser. You may override it by scrolling to the end of the page and clicking the gears icon.

Intel proposes x86-S, a redux of the x86 architecture

Is this a good idea?

  • Yes

    Votes: 32 69.6%
  • No

    Votes: 14 30.4%

  • Total voters
    46
I don't think the people who decide on this drastic change care about old games. Far more important is legacy code of industry/financial services and military. These types of large organizations need to know if their code can run on new hardware in case of expansion, replacement or tech consumables like smart bombs.

Most programmers today are platform independent high-level programmers who don't directly work with the computer architecture. What Intel definitely needs is the support of the compiler teams of many modern programming languages.
 
Presumably any software needing legacy 16 or 32-bit is so old that modern CPUs can run it plenty fast enough even with a 50x penalty to performance through software emulation.

Backwards compatibility and legacy support is definitely hurting x86.
 
I really don't know if this really matters that much, once instructions get turned into micro ops the ISA becomes effectively irrelevant.
 
I really don't know if this really matters that much, once instructions get turned into micro ops the ISA becomes effectively irrelevant.

Booting directly to 64 bit mode could improve startup times I suppose, and maybe harden security a bit by reducing the attack surface to only what's relevant to modern software?
 
Booting directly to 64 bit mode could improve startup times I suppose, and maybe harden security a bit by reducing the attack surface to only what's relevant to modern software?

Perhaps but I don't know if it's worth the colossal hassle of redoing x86, there is so much legacy stuff out there a lot of corporations/institutions wouldn't even want to hear about it.
 
Perhaps but I don't know if it's worth the colossal hassle of redoing x86, there is so much legacy stuff out there a lot of corporations/institutions wouldn't even want to hear about it.
They will be forced to "get by" with just AM5 and LGA 1700 (worst case), oh no ? [/s]
 
Last edited:
Booting directly to 64 bit mode could improve startup times I suppose
Improve startup times how?

I suspect the bottleneck is hardware device initialization. If so, that probably has more to do with UEFI standards, code, and the implementations of the external hardware devices (including those integrated on the CPU package).
 
Bootup on my FX is fast, same with the AM4, just like a CRT TV.
 
Improve startup times how?

I suspect the bottleneck is hardware device initialization. If so, that probably has more to do with UEFI standards, code, and the implementations of the external hardware devices (including those integrated on the CPU package).

CPUs initialize several times until reaching 64-bit operation mode. But I suppose the time it takes to do so is insignificant really
 
Bout Friggin Time....Legacy crap this, legacy crap that....

IMHO, if you STILL need 8, 16, or even 32bit compatibility in your processors for whatever reason, you may wanna consider another path in life...

they shoulda gotten rid of this stuff years ago and just pushed everyone to keep moving forward and keep pace with the modern world :D
 
It's ironic, remove the old crap and all that's left is AMD64, the irony lmao. You don't need Intel base anynore. Ofc, I'm being facetious cuz I don't know what's invloved, but on the surface its funny as hell.
 
It's ironic, remove the old crap and all that's left is AMD64, the irony lmao. You don't need Intel base anynore. Ofc, I'm being facetious cuz I don't know what's invloved, but on the surface its funny as hell.

That much seems obvious, because x86 and AMD64/EM64T have a symbiotic relationship on a modern PC.

x86 would operate on its own without 64-bit extensions (within its limitations) but never the other way around.
 
Cost cutting and product focus, which is in the priority of Intel, right now.
Otherwise they would be able to do concepts like x86S, it requires funding to research. TBH, not that surprising that it was canned for now.
 
I would like to know what percentage of fewer transistors (transistors from old technologies that were excluded) the X86S architecture will bring.
The smaller the die area, the cheaper it is to produce the CPU.

Did Intel take any inspiration from the RISC-V architecture when designing the X86S?
 
My personal concerns, for example, how would this affect old video games that we boot in DOS mode?
Hm, what are the latest CPUs that can run bare DOS? (Bare DOS probably includes Windows 3.11 and Windows 95 but I'm not sure here.)
 
I would like to know what percentage of fewer transistors (transistors from old technologies that were excluded) the X86S architecture will bring.
The smaller the die area, the cheaper it is to produce the CPU.

Did Intel take any inspiration from the RISC-V architecture when designing the X86S?
I think that all of this is kind of pointless both from a die area POV and boot time POV. The transistor budget for the legacy tech is very small and stable over time, gaining back die area is not a significant benefit here and with each node shrink that die area benefit would get smaller and smaller. It is the same reason why ARM's supposed ISA advantage over x86 was not really a ISA advantage per say, the die area benefits are just too small and getting smaller all the time.

Same with boot times, the other factors that affect boot times are much more important than how long the CPU uses legacy modes to boot into a system.

There are other benefits but those are mainly for Intel, not the end user.

From an implementation perspective, this was always going to end with Intel falling on its face because Intel is not dominating in the x86 market the way it was in the 90s vs AMD. It does not have the overwhelming industry heft to do this unilaterally. Better that both companies work together with other partners in a broader way as Intel is now doing with the x86 Ecosystem Advisory Group.
 
Hm, what are the latest CPUs that can run bare DOS? (Bare DOS probably includes Windows 3.11 and Windows 95 but I'm not sure here.)

Surprisingly... any of them will, at least on the Intel side. @OMORES has a pretty good YouTube channel where he runs all sorts of ancient operating systems on stuff as new as 14th Gen, worth checking out


From an implementation perspective, this was always going to end with Intel falling on its face because Intel is not dominating in the x86 market the way it was in the 90s vs AMD. It does not have the overwhelming industry heft to do this unilaterally. Better that both companies work together with other partners in a broader way as Intel is now doing with the x86 Ecosystem Advisory Group.

I reckon it comes down to this at the end of the day. Intel would have ultimately strong-armed this through - if they had the market share to do so. It's a missed boat, alright.
 
I think that all of this is kind of pointless both from a die area POV and boot time POV. The transistor budget for the legacy tech is very small and stable over time, gaining back die area is not a significant benefit here and with each node shrink that die area benefit would get smaller and smaller.
There are other benefits but those are mainly for Intel, not the end user.
Maintenance and security at least, and maybe more. Implementing 32-bit protected mode etc is still an engineering effort, relatively small, but that doesn't mean it's trivial. And it may open new security holes.

Intel would have ultimately strong-armed this through - if they had the market share to do so. It's a missed boat, alright.
Intel could do it alone. I don't see how that could hurt them. New server, workstation and laptop CPUs would no longer boot 32-bit OSes. So what. Would they lose market share because of that?

(I assume everybody understands by now that X86S processors would still run 32-bit applications natively, without the need for emulation.)
 
Last edited:
Maintenance and security at least, and maybe more. Implementing 32-bit protected mode etc is still an engineering effort, relatively small, but that doesn't mean it's trivial. And it may open new security holes.
Again, those are benefits for Intel, not the end user as I mentioned.

I don't see many (any?) security issues with the old instructions, it is always speculative execution attacks like Spectre or other recent technology. That suggests that the older technology is pretty time-tested and battle-hardened or that the security needs are not significant or technically difficult.
 
Again, those are benefits for Intel, not the end user as I mentioned.

I don't see many (any?) security issues with the old instructions, it is always speculative execution attacks like Spectre or other recent technology. That suggests that the older technology is pretty time-tested and battle-hardened or that the security needs are not significant or technically difficult.
Intel trying to change the rules because their keister was handed to them by AMD
 
Back
Top