32 Bitar Blir 64 Sammanfattning Syftet med rapporten är att ge en insyn i det tillvägagångssätt och problem som uppstod i utvecklingen från 32 bitars CPUs till 64 bitars CPUs samt inblick i skillnaden mellan 32- och 64 bitars CPUs. 32 bitars CPUs kan adressera 4GB av byte-adresserat minne. Detta var en tillräckligt stor buffert för minne att växa i då man inte var i närheten av att använda så mycket som kunde användas. Med tiden så blev minne både större och billigare och 4GB var inte tillräckligt längre och en lösning var då att öka från 32- till 64 bitar för att kunna adressera mer. Nya standarder och datamodeller behövde bestämmas och binärer behövde vara uppåtkompatibla för att fungerar med det nya. Att göra om utan att tänka på den redan installerade användarbasen går ej och de som funkar nu måste också funka på det nya i alla fall för en bit framöver.
Bakgrund Vad är det som definierar om en processor (CPU, engelska: central processing unit) är 32- eller 64 bitar? En N-bitar stor CPU tillämpar en instruktionsuppsättning (ISA, engelska: instruction set architecture) med Integer(heltals) register på N-bitar, ett antal (kan skilja sig från CPU till CPU) N-bitar ALUs och N-styck adresseringsbitar. Antalet adresseringsbitarna kan skilja sig genom att vara färre. Storleken på en CPUs flyttalsregister och databuss kan också skilja sig från de N-bitarna. Antalet bitar som en CPU kan manipulera på en gång kallas world size. En CPU med 64- bitars word size kan då processera 64 bitar per instruktion. Ett register på 32 bitar kan lagra 2 32 olika värden. En CPU med 32 bitars minnesadresser kan då direkt adressera 4GB av byte-adresserat minne. Ökar man till 64 bitar så ökar både antal olika värden som kan sparas och minne som kan adresseras oerhört. Ett register på 64 bitar kan lagra 2 64 olika värden. En CPU med 64 bitars minnesadresser kan då direkt adressera 1.8EB (1.8 eksa byte (10 18 ), 1.8 trillioner byte) av byte-adresserat minne. Hur mycket som man sedan kan använda av ens RAM i systemet beror helt och hållet på vilket operativsystem man kör och ytterligare utrustning i systemet. Nedan följer två tabeller som visar kompatibiliteten mellan CPU, OS och applikationer/program som kör 32- eller 64 bitar. Tabell 1 - Kompatibilitet med 32 bitars CPU Processor (CPU) 32 bitar 32 bitar 32 bitar 32 bitar Operativsystem (OS) 32 bitar 32 bitar 64 bitar 64 bitar Applikation/Program 32 bitar 64 bitar 32 bitar 64 bitar JA NEJ NEJ NEJ Tabell 2 - Kompatibilitet med 64 bitars CPU Processor (CPU) 64 bitar 64 bitar 64 bitar 64 bitar Operativsystem (OS) 64 bitar 64 bitar 32 bitar 32 bitar Applikation/Program 64 bitar 32 bitar 32 bitar 64 bitar JA JA JA NEJ
Inledning I sin artikel The Long Road To 64 Bits publicerad i Communications Of The ACM år 2009 skriver John Mashey om utveckligen från 32 bitars processorer till utbyggnader på 32 bitar och tillsist en full 64 bitars processorer. Mashey tar upp fundamentala problem som ledde till utökningen av bitarna på en CPU och problem som behövde lösas under vägen till 64 bitar. Att adresseringsutrymmet tar slut är ett vanligt problem inom datavärlden skriver Mashey. Kapaciteten för DRAM ökade och blev då också billigare att tillverka. När priset sänks så har mer människor råd med mer minne och 2 till 4GB blev vanligare bland konsumenterna. Vanlig adressering med 32-bitar började då bli för lite. Mashey tycker att 64 bitars processorer redan skulle ha börjat att skickas runt 1992 så att de blivit väl etablerade innan de verkligen behövdes. Istället för att ha uppgraderat system som bara kör 32 bitar så hade man kunnat byta till 64 bitars system och fått ett mycket smidigare byte. Mashey beskriver att tiden för skeppningen skillde sig mellan just barely in time (s.46) till rather late (s.46) och understryker att detta är mycket märkvärdigt med tanke på att samma problem har uppstått antal gånger innan och samtidigt med tanke på hur förutsägbar Moores lag är. Virtuellt minne kan adresseras av vilken CPU som helst genom användningen av flat addressing. Flat addressing fungerar genom att alla eller övervägande del av bitarna i ett heltals register används för en virtuell minnes adress som då kan vara större eller mindre än det fysiska minnet. Mashey förklarar att det har funnits åtskilliga klumpiga utökningar av bitar för att öka åren på en produkt innan den inte är brukbar längre. Nuvarande 32 bitars binärer behövde vara uppåtkompatibla för att kunna köras på de nyare 64 bitars systemen då många mindre system inte behövde 64 bitar. Mashey belyser att 32 bitar inte bara var en fas som man kunde glömma bort. För att lösa detta problem med uppåt kompatibilitet så behövde mjukvarudesigners komma överens om vissa standarder för kompilatorer och bibliotek samt att modifierar källkod för applikationer så det fungerar i både 32- och 64 bitars miljöer. Själva hårdvarulösningarna för detta var för det mesta enkla och Mashey skriver att lösningen för att öka storlekarna på register från 32- till 64 bitar inte var speciellt dyrt att göra och att processorernas area ökade med max 5%. Den redan etablerade 32 bitars arkitekturen för CPUs användes för de nya 64 bitars CPUs. De gjordes som utökningar genom att förlänga register till 64bitar och sedan ignorera de övre 32 bitarna när CPUn körde i 32 bitar. När det gällde mjukvarulösningarna så var det en annan femma. Vilka standarder som skulle gälla och konkurrens och samarbete mellan stora företag gjorde att vägen till en lösning blev mycket komplex.
Som Mashey skrev så är ändringarna för mjukvara från 32- till 64 bitar mycket svårare att genomföra. För inbyggda system som spelkonsoler så var bytet lätt men när det kommer till mer allmänna system som är öppna för användare så blir processen att byta mycket svårare. De allmänna systemen fick oftast gå igenom en längre process för att få igenom ett bra uppåt kompatibelt system. Nedan följer en sammanfattad lista av processen. 1. Skicka 64 bitars system som fortsätter att supporta 32 bitar. 2. Bestäm standarder för programmering i 64 bitar för programmeringsspråk. 3. Bygg kompilatorer som kan generera kod för 64 bitar. Kompilatorerna själva körs till största del fortfarande själva i 32 bitar. Beroende på storleken på programmen som ska kompileras så måste också kompilatorn att köra i 64 bitar. Kompilatorn får först justeras för att ta emot 64 bitar och sedan byggas om för att själv använda dem. 4. Ändra operativsystemen till 64 bitar som fortfarande kan hantera 32 bitar. Utforma nya 64 bitars systembibliotek av de 32 bitar som redan finns. 5. Skicka det nya på ny 64 bitars hårdvara och se till så att de funkar på den hårdvara som redan skickats sedan innan. 6. Övertyga tredje parts utvecklare att ändra mjukvara för att köras i 64 bitar. 7. Fortsatt support för system som kör 32 bitar men sluta att leverera nya system med 32 bitar. 8. Stoppa supporten helt för system som kör 32 bitar. Mashey understryker att det tar olika många år mellan stegen och att industrin inte kommit till steg 8 ännu. Användarbasen för 32 bitar och fortfarande stor. Program och applikationer kan såklart byggas om för 64 bitar genom att kompilera om källkoden i en kompilator som kör 64 bitar. Koden kan också behöva skrivas om på grund av vissa datatyper blir större då datamodellen ändras. Mashey betonar att många program som är för 32 bitar inte kommer att behöva köras i 64 bitar då dagens operativsystem tillåter minnespekare på 64 bitar för 32 bitars program.
Referenslista MASHEY, J 2009, 'The Long Road To 64 Bits', Communications Of The ACM, 52, 1, pp. 45-53, Business Source Complete, EBSCOhost, viewed 24 November 2015. PATTERSON, D.A & HENNESSY J.L (2014). Computer Organization And Design: The Hardware/Software Interface, 5th edn. Morgan Kaufmann. Microsoft 2015, Memory Limits for Windows and Windows Server Releases. Available from: < https://msdn.microsoft.com/en-us/library/aa366778(v=vs. 85).aspx>. [1 December 2015].