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

[dragorth]

This implies a tightly packed virtual space. I can see some uses for a really vast but sparsely populated VM space. Look at IPv6 and how it "recklessly" throws heaps of addresses at anyone just because it can. E.g. (increasingly insane yet possibly achievable):
- there are data structures that could be built on an assumption that VM space is enormous yet largely unpopulated. E.g. SuperMalloc allocates 512MiB vector for its internal use, and then usually only touches handful of entries into that vector. Due to that, only handful of physical pages gets allocated - its essentially a trie implemented by the hardware!
- preallocate few TBs of VM space for _every_ allocation that could possibly grow, and never have to move your data around just because you've ran out of address space.
- drop address space switching and go for a unified virtual memory view (e.g. allocate high bits of any address for a process identifier), using HW memory protections for security - I could see new IPC schemes going on here
- heck , let's add that IPv6 on top of that, and have every machine in the world share same virtual address space! No more downloading stuff; just mmap your URL and get a pointer into another server's area which you could just read.

Do you mean like the Mill's architecture that uses a flat address space externally but has internal virtual address space for the CPU? It does this in 64bit space, however.

We are perhaps passed the time we should be referring to CPUs as 64bit or 128bit, however. What are we referring to, exactly? When current CPUs can handle data sizes as large as 2048 bits, we should perhaps be a bit more specific and just say it is a 128bit memory architecture, because realistically, we don't need more than 2^64 instructions. And that is the Mill that combines instructions in such a way to encode up to 32 general purpose operands in one instruction, compared to something like SIMD style instructions that perform the same action on all parts of one piece of data that is much easier to encode.

[drakonas777]

Intel didn't increase prices of CPU through all the years they had dominance since core 2 duo. In fact AMD are experts in increasing prices, Literally first mainsteam CPU model since like ~~2000s consumer market 1031$ cpu is ... AMD-FX57, 18 years ago and if you adjust for inflation price that is 1600$. In fact Intel is the one that dropped prices over the years, Intel had few 999$ cpus like i7-975, etc. but just a little less clocked same version of CPU (960) was 562$. Now 13900k MSRP is joke comparing to those old prices and we are after massive inflation.

Invalid comparison. First of all, there was a Pentium 4 Extreme Edition for a 999USD before FX. It was announced only a week before, but still technically before Also, back in Athlon64/FX days there was no HEDT segment as such. Yes, AMD did ask a grand for a top SKU, however, Intel invented "HEDT" soon after it and asked up to several grands in some instances. Also, Intel introduced that bullshit i9 branding into the mainstream platform with 9900K release, which bumped the price of a top mainstream SKU by quite a bit (and indirectly lower SKUs by some amount). So yeah, "Intel didn't increase prices" my ass.

[debrouxl]

Removing rings 1 and 2 because they're unused by modern software, instead of improving them so that they're more widely usable, and thereby further constraining kernel + user-space development on X86-S for decades, is a form of throwing the baby out with the bathwater...
I recently learned from a discussion, then looked for myself and found https://en.wikipedia.org/wiki/OpenVMS -> https://www.youtube.com/watch?v=U8kcfvJ1Iec , that and why the x86-64 port of OpenVMS does not use rings 1 and 2 for implementing the 4 privilege levels provided by that OS - they can't - and how they have to jump through hoops to emulate 4 privilege levels with only 2 usable hardware rings. This seems to have played a (significant ?) role in the complexity of porting OpenVMS to x86-64.
X86-S is breaking some compatibility with x86 / x86-64 anyway, so they could break it slightly more, in order to improve the ISA. AVX512* + AMX certainly costs much more, in terms of transistor count and processor testing time, than rings 1 and 2.

Sure, the virtualization layer of x86-64 provides "ring -1", as do EL2+ privilege levels of modern ARM versions, but virtualization extensions aren't the only possible answer to a possible need for more than 2 privilege levels for some higher security / reliability / isolation designs (micro-kernels also come to mind).

In another area, X86-S would be an opportunity to mandate various security and non-security features, but it's not taken by this first version of the X86-S EAS. The AVX512* + AMX mess should be out, by all means, but a large subset of the AMD-implemented/implementable extensions brought by "x86-64-v4"-era Ice Lake or Sapphire Rapids over Haswell-era "x86-64-v3", which is a decade old at this point, could / should be in: SMAP (only Broadwell+; Haswell already has PCID + SMEP + INVPCID, and it took years until AMD finally implemented all four), CET IBT+SS (for what they're worth), crypto / hashing acceleration instructions, fast rep mov, etc.

[goetz]

Came here to say the same.

They haven’t learned to be humble.

I hope that AMD keeps taking market share away, so Intel continues losing money.

its going to be hard though. At work, we are a Dell/Intel shop(over 20K heads) and no matter what, they dont even consider buying any other brand or with Ryzen. One of them told me with a straight face that Ryzen is not 100% compatible with Windows and Linux programs like Intel is.

Multibillion company IT dept run by morons.

It has nothing to do with linux of windows incompatibility but if you need perfect reproducibility of floating point computations you cannot switch.

[user1]

In fact if not for AMD we'd be paying $4,000+ for a crappy four core Intel microprocessor at this very moment.

Lol, you serious?
AMD is the one who increased the price of all of their Zen 3 cpu's by 50 dollars compared to Zen 2. And that's already when it had strong competition with Intel. Intel on the other hand, didn't do such thing even when it had zero competition from AMD between 2014 and 2017.
But it seems AMD fanboys hate facts, so they write such nonsense...

[jacob]

too late. Risc-V 64bit is going to eat x86 for breakfast.

Maybe within the next 50 years we will evrn see a RISC-V core that's performance competitive with the 486 for under $20,000

[Rallos Zek]

x86 is an ISA where you cannot specify different source and destination registers for bit shifts. Using them requires either doing a mov instruction or clobbering the original value. Both ARM and RISC-V support both source and destination registers in their bit shift instructions.

x86 has over 10,000 instructions (or op code/prefix combinations in Intel’s misleading nomenclature) just for SIMD, which waste die area that could be used on better things. Intel originally planned to add even more instructions for 1024-bit SIMD, but their recent troubles with 512-bit SIMD make that seem unlikely. RISC-V on the other hand implemented support for 128-bit, 256-bit, 512-bit, 1024-bit and 2048-bit SIMD with only 171 instructions. ARM did not follow Intel in adding instructions for above 128-bit SIMD until it copied RISC-V to enable it via SVE/SVE2. Best of all is that the RISC-V approach lets you execute 2048-bit SIMD instructions on hardware that only supports smaller SIMD widths by having the hardware implicitly use the smaller width units multiple times. That means that you can often write software only once and have it benefit from newer hardware without having to rewrite/recompile it. This is a substantial time savings for developers and allows users to leverage hardware improvements sooner.

Both ARM and RISC-V are objectively better then x86. In the past, Intel kept x86 on top in the past through a process technology advantage, but that is gone. Now others are able to compete on technical merit, so x86 is naturally losing ground to them, despite x86 having the benefit of inertia. Being forced to compete on merit is why Intel backpedaled on AVX-512 and is looking to throw the other anchors wasting die area overboard, which led to their x86-s plans. That would also be why they have become much more conservative in adding extensions, since they cannot afford the die area cost without a process advantage.

This post falsely assumes either ARM or RISC-V are objectively better than x86. Nothing you wrote provides objective proofs that either ARM or RISC-V is better, and sounds like me back 20 years ago claiming that the Sega Dreamcast was better than PS2 or Xbox

[rmoog]

And that's why I don't understand the hype around ARM / RISC-V. Maybe those who're hyped about ARM / RISC-V don't give a damn about backwards compatibility, but it's something I deeply care about.

I care about backwards compatibility only where it matters, i.e. in maintaining machines that work with DOS, Windows 98, XP, OSX 10.4, but beyond that everything I use is free software and therefore I do not need to be hamstringed by limitations of original releases. In ARM and $800-for-ultra-lowend-SoC-without-PCIE-V, you don't need backwards compatibility because you are extremely unlikely to be running proprietary software on them, because proprietary software isn't widely available for those architectures. For x86 backwards compatibility is all the rage because you can milk all the gamers from their money by never recompiling your Windows 98 binaries as long as you provide enough hacks for their games to work on current Windows. Nobody in server business takes an x86 and say "oh gosh darn golly gee willickers! how will I live without being able to run database software from 2001 in year 2050! better buy x86!". The only reason x86 stays in server business is because it's dirt cheap.

[Rallos Zek]

If you want a vibrant ecosystem, RISC-V is where the momentum is.

All those non-free proprietary chips do make for healthy ecosystem.

[rmoog]

x86 -- 32-bit
RISC-V has the R in its name (reduced), which is why I hope it succeeds.

Way to reinforce a point.

Currently it's in its infancy

jUsT 2 mOrE wEeKs GuIsE!1
It's been in its infancy for 5 years! I was hopeful for RISC-V to be a serious architecture but all I got was:
- $800 SoCs that aren't really that good
- if you add $400 more to the pricetag you'll get 1 PCIE
- you're lucky if that PCIE port is better than x1 and if it is, it's probably a temporary mistake, rest assured that the sweatshop owners will reimburse themselves by not paying their product owner their generous salary of 0.5 bowl of rice per day
- tons of unpaid shills on telegram and /g/ telling me that I just need to wait 2 more weeks before the good stuff arrives, you know, stuff that can at the very least decently compete with RPI4 in terms of buck/dollar
- absolute bumbling cobblers calling me names and trying to cancel me because I dare voice my criticism against this situation
- the promised vaporware shit the shills promised never arrived

When do we accept that the current state of RISC-V is a crapshoot?