Intel Publishes "X86-S" Specification For 64-bit Only Architecture

[ryao]

Since they are envisioning a cleaner ISA, nothing stops them from using something similar to the RISC-V architecture approach for this new x86s architecture. It wouldn't be the first time they backpedaled on a set of instructions, and you can emulate the extra instructions if the 171 cover most use cases.

That doesn't mean they will do it, however.

They could add it as an extension, but that is not going to improve the situation for them. They are drowning with technical debt from many past bad architectural decisions that were masked by a process advantage that they no longer have. Adding instructions is like pouring oil on a fire and it is not really going to help them compete unless they can get rid of existing extensions. However, legacy support means they are locked into many of those extensions. They cannot for example, drop AVX/AVX2 support without losing performance since software will not be automatically rewritten to use the new extension, and losing performance is counterproductive for them. They would need to invent a time machine to stop themselves from making MMX in the 90s and adopt the equivalent of the RISC-V Vector extension then.

[direc85]

x86 -- 32-bit
x86_64 -- 32/64-bit
x86s -- 64-bit

Did they hire the same guy that names Windows versions? Was x64 taken? Was x86_64s too long?

While I do appreciate the effort to simplify the architecture, it's very likely that binaries are not cross compatible either way. If that's the case, some slightly more aggressive instruction removal/replacement would certainly be in place. x86_64 ISA is a mess, to put it mildly. My go-to example to drive the point home: https://m.youtube.com/watch?v=g9_FYRAfyqQ
RISC-V has the R in its name (reduced), which is why I hope it succeeds. Currently it's in its infancy, and until one of the two big players start making good hardware for everyday home users, the x86 family will reign.

Edit: I hope this is a let's-start-discussion draft, and Intel works with AMD on this, so the industry gets the best possible result.

[user1]

Backward compatibility does not require the hardware to support the same ISA indefinitely. Apple achieved backward compatibility in software through binary translation in Rosetta 2

I know about the various translations like box86 and others, but it seems Rosetta 2 is the only one that is truely performant. Problem is that Apple almost certainly won't keep it forever. If Apple ditched Rosetta 1 only after a few years, there's no reason to think it won't do the same to Rosetta 2.

[ryao]

I didn't see a single mention of consolidating or making a baseline of SIMD instructions. That means x87, MMX, MMXExt, SSE 1-4xx , AVX 1/2/512, and others all are still there, and all still have/need competing levels/hierarchies of overlapping functionality. I think they should re-baseline the SIMD they have/want to a new superset, and emulate many of the older SIMD instructions by technically running them on the microops for their more advanced SIMD platforms.

The idea is to maintain backward compatibility with existing software while freeing transistors to be used to make better processors for existing software. They are not likely to do anything particularly breaking such as removing extensions used in existing userland software. That would require losing the advantage of inertia from backward compatibility.

I still want my POWER back. Libre-SoC news anyone?

https://www.powerpc-notebook.org/en/

[ryao]

x86 -- 32-bit
x86_64 -- 32/64-bit
x86s -- 64-bit

Did they hire the same guy that names Windows versions? Was x64 taken? Was x86_64s too long?

While I do appreciate the effort to simplify the architecture, it's very likely that binaries are not cross compatible either way. If that's the case, some slightly more aggressive instruction removal/replacement would certainly be in place. x86_64 ISA is a mess, to put it mildly. My go-to example to drive the point home: https://m.youtube.com/watch?v=g9_FYRAfyqQ
RISC-V has the R in its name (reduced), which is why I hope it succeeds. Currently it's in its infancy, and until one of the two big players start making good hardware for everyday home users, the x86 family will reign.

Edit: I hope this is a let's-start-discussion draft, and Intel works with AMD on this, so the industry gets the best possible result.

They are still going to support 32-bit software, but it must run on top of a 64-bit kernel.

[ryao]

I know about the various translations like box86 and others, but it seems Rosetta 2 is the only one that is truely performant. Problem is that Apple almost certainly won't keep it forever. If Apple ditched Rosetta 1 only after a few years, there's no reason to think it won't do the same to Rosetta 2.

That would be because Apple added hardware extensions to make performant binary translation easy:

https://dougallj.wordpress.com/2022/11/09/why-is-rosetta-2-fast/

If other ARM hardware adopted these extensions, everyone could have performant x86 binary translation on ARM hardware.

That said, Apple was still selling intel hardware until a year or two ago, and it is still building new MacOS versions for them. That should continue for at least another 4 years. It would make sense for Apple to support Rosetta 2 for at least that long.

[NeoMorpheus]

x86 -- 32-bit
x86_64 -- 32/64-bit
x86s -- 64-bit

Did they hire the same guy that names Windows versions? Was x64 taken? Was x86_64s too long?

While I do appreciate the effort to simplify the architecture, it's very likely that binaries are not cross compatible either way. If that's the case, some slightly more aggressive instruction removal/replacement would certainly be in place. x86_64 ISA is a mess, to put it mildly. My go-to example to drive the point home: https://m.youtube.com/watch?v=g9_FYRAfyqQ
RISC-V has the R in its name (reduced), which is why I hope it succeeds. Currently it's in its infancy, and until one of the two big players start making good hardware for everyday home users, the x86 family will reign.

Edit: I hope this is a let's-start-discussion draft, and Intel works with AMD on this, so the industry gets the best possible result.

I have a feeling (mostly due to my ignorance but also by knowing how dirty Intel still is) that this is a move to lock AMD out of the x86 market.

[arteast]

I didn't see a single mention of consolidating or making a baseline of SIMD instructions. That means x87, MMX, MMXExt, SSE 1-4xx , AVX 1/2/512, and others all are still there, and all still have/need competing levels/hierarchies of overlapping functionality. I think they should re-baseline the SIMD they have/want to a new superset, and emulate many of the older SIMD instructions by technically running them on the microops for their more advanced SIMD platforms.

Like you said, it's a garbage collection. They are throwing out everything that isn't being used. Unfortunately, x86/MMX/SSE are all still in use by a 32-bit applications. Getting rid of these opcodes would hurt their userbase so they aren't doing it. As for emulating older instructions - surely they already do that; all these opcodes for all these SIMD families surely map to the same (maybe masked) uops going to the same vector-capable port, with x87 stack emulated by something like vector register renaming.

[piotrj3]

No, Intel wasn't first to propose 64 bit architecture. MIPS, Alpha and SPARC had 64 bit years before Intel introduced Itanium. Itanium itself wasn't even solely Intel invention - it was based on PA-RISC architecture from HP. Intel wasn't first in 64 bit x86 either. Itanium was not based on x86, it was completely different architecture only with x86 emulation. First x86 64 bit CPU was from AMD.

I am talking in context of x86 architecture because the post i was responding to was talking about x86. Of course i know there were 64 bit CPUs earlier, some even had production use. In fact we had even SEGA dreamcast released in 1998 that was in some way even 128bit CPU.

[ryao]

I have a feeling (mostly due to my ignorance but also by knowing how dirty Intel still is) that this is a move to lock AMD out of the x86 market.

Given that AMD and Intel cross licensed their instruction sets, this move is probably a gift to AMD more than anything else. Both of them are having trouble competing with ARM:

https://www.nextplatform.com/2023/05/18/ampere-gets-out-in-front-of-x86-with-192-core-siryn-ampereone/

Projections for upcoming ARM processors show much bigger leaps in competitiveness than either AMD or Intel currently have planned. If they do not do something to maintain some sort of advantage beyond backward compatibility, they will both be the next Cyrix.