Alla vet att Intels (och AMDs) x86-arkitektur är rätt stor och­ stökig. Det är en gammal arkitektur med rötterna i 1970-talet som har uppdaterats från 16 bitar till 32 bitar och sedan 64 bitar.

Det har lagts till mängder av nya instruktioner för att
effektivisera vanliga beräkningar (flyttal, krypto, vektorer, bitmanipulering, matriser, …). Systemmodellen har utökats med funktioner för minneshantering, virtualisering och säkerhet.

Men hela tiden har befintlig programvara fortsatt att fungera. Intel och AMD har hållit hårt i bakåtkompatibiliteten.

x86s sätter punkt för detta och markerar på många sätt ett nytt synsätt på hur x86 ska utvecklas fram­över som påminner mer om hur ARM har hanterat sina arkitekturvarianter (jag skriver det i plural eftersom det finns flera ”ARM” som är helt inkompatibla med varandra). 

X86S står enligt Intel för ”x86 simplification” och ska skrivas x86S (litet x, stort S, inget bindestreck). Det är en specifikation som just nu, i version 1.2, är på 58 sidor och beskriver ett antal ändringar till x86-arkitekturen. En första version kom i april 2023, och den nuvarande versionen släpptes i juni 2024. Intel har uppdaterat specen baserat på feedback – ändringar av den här ­magnituden behöver diskuteras både internt och med ­olika partners i ekosystemet. 

Kompatibilitet

En nyckelfråga när man utvecklar en ny processorarkitektur är hur man ser på bakåtkompatibilitet. Ska befintlig kod fungera på den nya arkitekturen? Och mer intressant: vilken befintlig kod ska fungera? 

Grovt kan man dela in mjukvaran i fem delar som visas i bild 1 nedan (klicka för större bild!)

När en dator idag startar går den först igenom en säker start, där mjukvara som är bokstavligt inbränt i chipet körs. Koden här kommer typiskt från kiseltillverkaren och är väldigt tätt kopplad till en viss kiseldesign. 

Nästa fas i starten är den traditionella ”bootloadern”, eller laddaren. På en PC brukade detta kallas BIOS, Basic Input-Output System. BIOS tillhandahöll en miljö från vilket ett operativsystem (eller ”bare metal”-kod) kunde köra. Under 2010-talet tog UEFI över. UEFI har ett annorlunda gränssnitt mot operativsystemet (OS) och OS behövde uppdateras för att starta från UEFI. I PC-världen finns en handfull leverantörer av UEFI-laddare, plus att de flesta stora tillverkare som Dell, Microsoft och Lenovo har sina egna UEFI. 

Efter laddaren kommer idag normalt en hypervisor som delar hårdvaran mellan ett antal virtuella maskiner. Microsoft har sin Hyper-V, VMWare är vanligt på servrar, och molnföretag brukar ha sina egna lösningar eftersom de säljer virtuella maskiner. Virtualisering har blivit väldigt vanligt och det är en del av bakgrunden till x86S.

Operativsystemet är den mest välkända nivån, med Linux, Windows, BSD och realtidsoperativsystem. OS kör antingen direkt på hårdvaran eller på en virtuell maskin som tillhandahålls av hypervisorn. Det finns betydligt fler varianter på operativsystem än hypervisors. 

BILD 2. Klicka för större bild!

Slutligen kommer användarprogrammen eller applikationerna. Det som de flesta användare bryr sig om. Dessa är tusentals gånger fler än operativsystemen. Oftast görs stora ansträngningar för att även riktigt gamla program ska fungera på nya system, eftersom användare tenderar att bli arga om deras nya dator har sönder deras befintliga program. Kompatibilitet för användarprogram handlar lika mycket om OSet som hårdvaran; bild 2 visar ett exempel på hur Windows 11 låter dig köra gammal mjukvara i en miljö som ser ut som äldre versioner av Windows.

En förändrad syn 

Den traditionella synen hos x86-tillverkare var att all gammal mjukvara skulle fungera på ny hårdvara, inklusive OS. 

Om någon vill köra en gammal DOS från 1990-talet på en sprillans ny server 2024 så ska det fungera. Man vet ju aldrig vilken viktig kund som man kunde tappa om man hade sönder någonting. Detta tänkande har genomsyrat hela x86-ekosystemet. Till exempel kan man i många UEFI fortfarande slå på kompatibilitetsläge som låter dig starta maskinen i BIOS-läge för att låta riktigt gamla operativsystem starta. Trots att UEFI varit standard i mer än tio år. Men man vet ju aldrig … 

På senare år har detta börjat ändra sig. Med en ökad användning av molntjänster och virtuella maskiner rör sig operativsystemen bort från hårdvaran. Mjukvaran på applikationsnivån mer och mer oberoende av den underliggande arkitekturen och enklare att portera, mycket drivet av intåget av ARM-arkitekturen i ”vanliga datorer” och inte bara i mobiltelefoner. 

Att bibehålla strikt bakåtkompatibilitet hela vägen tillbaka till laddaren är helt enkelt inte lika viktigt idag, och med det blir kompatibiliteten en kostnad som inte nödvändigtvis betalar sig. Färre och färre användare har nytta av maxad bakåtkompatibilitet – om man kör sin mjukvara i en ”container” på en generisk Linux på en virtuell maskin på en molntjänst ser man inte hårdvaran alls. Men det kostar hårdvarutillverkare tid och pengar att testa och validera bakåtkompatibiliteten även när den inte används. 

Därav x86S – det handlar om att ta bort funktioner i hårdvaran som inte längre används av majoriteten av mjukvaran. För att göra det lättare att bygga ny hårdvara och mjukvara. 

Enklare start

Den kanske största förenklingen i x86S är att den ändrar hur datorn startar. Ända sedan 8086:an på 1970-talet har en x86 dator startat i 16-bitarsläge. För att komma upp i 32-bitarsläge och senare 64-bitarsläge fick mjukvaran, typiskt laddaren, köra speciell kod. Idag när i princip alla operativsystem som körs är 64-bitars är detta helt poänglöst. 

BILD 3. Klicka för större bild!

Bild 3 illustrerar skillnaden i hur datorn startar. Det är värt att notera att det klassiska startflödet lät systemet stanna i 32-bitarsläge och köra 32-bitars operativsystem. 64-bitsläget kom till som en valfri utökning senare och under de tidiga åren av ”x86-64” var det väldigt vanligt med 32-bitarsoperativsystem. Det tog ett tag att få upp all mjukvara på 64 bitar. Jag minns diskussioner från den tiden om hur 64 bitar gjorde kod och data större och riskerade göra mjukvara långsammare. Men det var tjugo år sedan. 

X86S gör det enklare för mjukvaran – men det kräver att både laddare och operativsystem uppdateras. Den tidiga startkoden kommer behöva skrivas om rejält. Det är inte stora mängder kod, men utan ändringar kommer ingenting fungera. Detta skiljer sig från de tidigare utökningar och ändringar som gjorts för x86, där gamla mjukvarustackar fortsatte att fungera även om de inte drog nytta av det nya. Som sagt ovan representerar detta ett nytt tänkande inom x86-världen. 

Andra förenklingar

Listan på det som stryks i arkitekturen är lång. 

Det är värt att notera att x86 kända ”ringar” försvinner. I praktiken får x86S samma uppdelning i OS-nivå och användarnivå som alla andra arkitekturer idag. Ingen använder mellanlägena i ring 1 och 2 – till stor del eftersom OS som Linux och Windows även fungerar på andra arkitekturer som saknar dem. 

En hel del saker förenklas också på systemnivån, som att man måste hantera interrupt med hjälp av X2APIC. Det kommer att vara möjligt att gå direkt mellan fyranivåers och femnivåers sidtabeller i MMU:n. 

Detta påverkar operativsystem och hypervisorer som behöver ändra koden som ligger närmast hårdvaran – men det är inte ett problem för de allra flesta. Förhoppningsvis innebär det att OS-koden krymper eftersom ett OS för x86S har ett enklare gränssnitt till hårdvaran. 

Vad går sönder?

X86S kommer inte vara ett problem för de som kör Windows, Linux eller BSD eftersom Intel och AMD kommer se till att det fungerar. Samma gäller för alla vanliga hypervisorer. Realtids-OS och andra mindre vanliga OS kommer behöva uppdateras om de vill fungera på nya x86S, men det är inget ovanligt om man tittar på andra arkitekturer. 

Det som definitivt kommer gå sönder är operativsystem som är skrivna för 32-bitars x86 eller använder gamla hårdvarumekanismer. Tack vare PC-ekosystemets öppenhet finns det många hobbyprojekt som använder de äldre och ofta enklare mekanismerna, men som måste gå över till UEFI-start, 64-bitarsläge, et cetera, om de ska fortsätta att fungera på framtida x86-hårdvara. 

Men. X86S-designen har en enkel lösning för de som behöver köra 32-bitars OS i framtiden: använd virtualisering. Även om inte hårdvaran i sig stödjer de gamla mekanismerna går det alldeles utmärkt att simulera dem i en hypervisor. I praktiken flyttas en massa komplexitet från hårdvara till mjukvara – och där kommer den bara finnas om den behövs. Annars kan man helt ta bort den från stacken, vilket gör allting enklare och minskar riskerna för säkerhetshål. Förenkling är som sagt temat. 

Det är värt att notera att 32-bitars användar­program fortsätter fungera utan några särskilda trick. Med andra ord precis som de idag. 

Fördelar för hårdvaran

Fördelarna med x86S för hårdvaran är att man tar bort en massa komplexitet och interaktioner mellan funktioner. Det blir lättare och roligare att designa nya processorer. Det blir speciellt mycket lättare att testa och validera dem. 

Det går ärligt talat inte åt så många transistorer för att implementera de gamla mekanismerna – de kom ju i en tid där man inte hade så stora transistorbudgetar. Men det är inte det som är problemet. Problemet är att regelboken för en x86:a är väldigt tjock. En x86S-processor kommer vara lika stor som en klassisk x86:a, men den kan bli snabbare och framförallt robustare och säkrare.

Med klassisk x86 måste Intel och AMD testa att alla gamla funktioner och mekanismer fungerar som de ska. Floran av olika exekveringsmoder skapar en stor testmatris – fungerar en ny instruktion korrekt i alla moder? Nya funktioner måste ta hänsyn till gamla när de designas, och det kan bli många specialfall som måste hanteras när olika funktioner och moder interagerar. Risken finns alltid att någon konstig kombination av gamla och nya funktioner skapar säkerhetshål. ”Feature interaction” är en rik källa till buggar och säkerhetshål både i mjukvara och hårdvara. 

Andra varianter av kompatibilitet

X86-tillverkarna och operativsystemsföretagen för PC har haft en ovanligt strikt syn på kompatibilitet jämfört med andra tillverkare och ekosystem. 

Apple, till exempel, har varit väldigt tuffa på app-nivån för telefoner. Gamla iOS-appar fungerar inte alls idag eftersom de har gått från 32-bitars till 64-bitars ARM. Programmeringsgränssnitt och krav rör på sig konstant. En utvecklare som inte aktivt underhåller en applikation får räkna med att den slutar fungera inom några år. Detta är väldigt annorlunda mot den klassiska PC-modellen. 

En helt annan hantering av kompatibilitet finns i ”IBM i”, tidigare AS/400. Det systemet har 100 procent bakåtkompatibilitet med applikationer tillbaka till 1980-talet. Applikationer kompileras till bytekod som sedan kompileras till den faktiska hårdvaran när de körs. Operativsystemet tillhandahåller ett stabilt och extremt kraftfullt gränssnitt – i praktiken en högnivåmaskin. Den underliggande hårdvaran och mjukvaran har ändrats drastiskt under huven genom åren, men det är ingenting som applikationer märker. ­Lådan är helt stängd, till skillnad från PC där lådan är väldigt öppen. 

För de flesta inbyggda system är kompatibilitet helt poänglöst, annat än som en bekvämlighet. Om all mjukvara som kör på systemet kommer från samma tillverkare kan man ju bara kompilera om allting om man byter processor. Inte ens instruktionsuppsättningen behöver vara densamma så länge som koden inte är assembler. 

Andra utökningar och ändringar för x86

X86S är inte den enda stora förändringen för x86 som Intel och AMD lanserat på senare tid. Intel har släppt specifikationerna för Advanced Performance Extensions, APX, som syftar till att göra vanlig kod mer effektiv. APX dubblerar antalet generella register till 32, vilket innebär att x86 skulle ha lika många som vanliga RISC-arkitekturer som ARM, RISC-V, och POWER. APX inför också många nya varianter på villkorliga instruktioner (”conditional instructions”) i syfte att minska mängden hopp i instruktionsströmmen. APX kan användas på alla nivåer i mjukvarustacken och kräver att program kompileras om. Precis som tidigare utökningar av x86. 

För ett par år sedan kom FRED, Flexible Return and Event Delivery. Detta är precis som x86S en förenkling på systemnivån. Vad jag kan förstå kommer x86S att inkludera FRED, men FRED är en egen oberoende specifikation som troligen kommer dyka upp i hårdvara innan x86S. Intel la till stöd i Linux för FRED redan i kernel 6.9, så det kommer kunna användas så snart som hårdvara dyker upp. 

I oktober 2024 tillkännagav dessutom AMD, Intel, och hårdvarutillverkare som använder deras chip att de skapat en ””. Målet är att minska skillnaderna mellan AMD och Intel och driva x86 framåt som en mer sammanhållen arkitektur. För användarprogram är skillnaden mellan Intel och AMD-chip idag förhållandevis liten, men på systemnivå har de två tillverkarna helt olika lösningar för viktiga funktioner som virtualisering och säkerhet.