Intel lägger ned x86S-initiativ

Tror att Idén i sig är körd. Enda fördelen med x86 är dess kompabilitet med gammal legazy. Tar man bort den enda fördelen som är kvar med bakåtkompabilitet hos x86 så finns det noll anledning att välja Intel. När det gäller allt annat så kommer ARM att dominera totalt (en ny, icke-x86-kompatibel instruktionsuppsättning kommer inte ha en chans att konkurrera).

Intel är rökta.

Vad är det för fördel enligt dig med att kunna köra native 16-bitars kod år 2024 (snart 2025) på en sprillans ny CPU när det ändå enkelt kan köras via emulering?

De måste ju sluta trimma den där gamla mopeden någongång. Droppa arvet och tänk om.
Kör en m4 pro i några minuter ifall ni undrar varför.

Varför skulle det bli en sådan enorm flopp? Jag förstår att det finns de som bryr sig om att boota i real mode och köra 16-bitars kod fortfarande, men vad gäller privatpersoner så är det nog ingen överdrift att 99.9% (999 av 1000) inte bryr sig om såna grejer. x86S kan fortfarande kunnat köra 32-bitars kod från mitten av 90-talet, så det är inga problem att köra gamla program och spel.

Tror även att en väldigt stor andel företag också klarar sig utan funktioner som skulle bort:

Många av dessa har varit fullkomligt irrelevanta förutom vid boot sedan... ja, 20 år sedan kanske? Och ett resten sedan 64-bitars OS blev standard.
Men visst, på datorer som kör DOS för att driva CNC-svarvar från 80/90-tal, eller köra tåg och allt vad de gör, så skulle det nog inte fungera.

En av huvudanledningarna till x86S är att man i praktiken inte kan köra 16-bit program längre sedan införandet av UEFI som saknar "legacy boot" alternativet (vilket är typ 100 % av konsumentdatorer idag).

Detta handlar primärt inte om att öka prestanda, utan så länge man har kvar funktionerna kostar det resurser att validera att dessa fungerar i nya designer. Vilket i sig är lite meningslöst när CPUn sedan placeras i en PC-dator som saknar BIOS för att köra detta läge.

Så på CPU-nivå stöds fortfarande allt, men på PC-systemnivå har vi i praktiken redan lämnat detta stöd.

Väldigt kritiskt här att hålla isär 32-bit Arm (A32) och 64-bit Arm (ARM64, med ISA A64). A32 och A64 är två helt separata instruktionsuppsättningar där A32 idag primärt används i billiga mikrokontrollers, A32 har sin stora fördel i att det kan ge väldigt kompakt kod (kompaktare än x86 och väsentligt kompaktare än "normal" RISC-kod).

Är A64 där man dragit iväg rejält från x86_64 i prestanda/cykel. Fanns ingen A32-CPU som bättre än x86_64 på detta. Men både Apple M4 och Arm (Cortex X925), båda är A64-only CPUer (initialt kunde de flesta ARM64 CPUer även köra A32), har ju en perf/Hz som ligger 40-50 % högre jämfört med Arrow Lake / Zen 5.

Det är bakåtkompatibilitet som allt mer håller tillbaka x86_64. Men det är inte bakåtkompatibilitet i form av "går fortfarande att köra 16-bit program".

Istället handlar det om andra typer av designval man gjort för x86/x86_64, några exempel är minneskonsistens (relevant i multitrådade program), hur instruktioner är kodade (orsaken till varför 10-wide ARM64 är relativt enkelt medan 8-wide x86_64 är nära nog raketforskning), hur tillstånd och data hanteras av instruktioner. ARM64 är bättre designad på alla dessa punkter jämfört med x86_64.

Det sista (hur tillstånd och data hanteras av instruktioner) är möjligt att ändra och ändå vara bakåtkompatibel, det lite på samma sätt som man idag fortfarande är bakåtkompatibel med 16-bit kod. Gissar att Intel väljer att fokusera på det istället för x86S.

Jobbet att förbättra tillstånd/data-hantering inom ramen för x86 kallas APX (Advanced Performance eXtensions).

Men APX har en stor nackdel: dagens program kommer se noll nytta av införandet av APX. För att utnyttja fördelarna här behöver man kompilera om programmet och program som faktiskt använder APX är inte bakåtkompatibla med dagens CPU-modeller då de saknar APX-stöd. Och om man kompilerar om, varför inte bara kompilera om till ARM64?

Så en CPU med APX är som dagens x86_64 CPUer: de är bakåtkompatibla + har ett "nytt" läge. Men "gamla" CPU-modeller kan inte köra kod som använder det "nya" läget.

Den här gången finns ändå hopp om att x86 tillslut får sin väldigt försenande pension. 2024 är första gången på 25-30 år där världens snabbaste CPU-kärna inte kommer från Intel eller AMD, utan den är Apples M4.

Hade det bara varit Apple kanske det inte betytt så mycket då de inte ens försöker ge sig på "mainstream" (Apple har flera gånger sagt att de inte vet hur man kan bygga en laptop under $1000 som inte suger, därför bygger de inte sådant).

Men under 2024 fick vi även Qualcomm Oryon (helt OK, men nog för lite-för-sent) och mindre än ett halvår senare Oryon 2 (Snapdragon 8 Elite) samt Arm X925 (t.ex. Mediatek Dimensity 9400) som båda presterar i nivå med senaste generationen desktop x86_64 räknat per kärna men är designade för mobiler.

Sett till råprestanda per kärna har inte x86 haft liknande konkurrens på mer än ett kvarsekel. Stora skillnaden är att förra gången var utmanarna lågvolymsprodukter i server-segmentet (SPARC, POWER, DEC Alpha, m.fl.), nu är det mobiler och bärbara datorer långt större volymer.

Finns hopp att Intel faktiskt är körda. Och om Intel är körda så är i praktiken även x86 körd (AMD är inte bra på programvara...). Vilket för oss kunder kanske ändå är önskvärt givet att allt mer pekar på att x86 är ett ankare för CPU-utvecklingen. Men säker kan man knappast vara, bl.a. APX kan mycket väl vara "tillräckligt bra" och ge x86 ett par decennier till...

Det vore dock skönt om vi fick fler ARM-plattformar med UEFI eller något liknande som inte beter sig som embedded-plattformar med device trees och annat sådant. De behöver kunna känna av inkopplad hårdvara dynamiskt vid boot (eller för den delen gärna hot swap också i form av PCI-E hotswap) och ha ett standardiserat sätt att boota dessa. Hårdvaran behöver också vara uppgraderingsbar, dvs. raka motsatsen till Apples nuvarande "stationära" datorer.