Intel lägger ned x86S-initiativ

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.