|
Flest bitar när han dör vinner |
|
13/10 -01 | Janne Johansson | jj@it.kth.se
Inledning
När jag började med datorer (1981)
så var alla hemdatorer
8 bitars. Det berodde ju mest på att det inte
fanns särskilt
många att välja på, och att de
flesta hade samma CPU
i sig. (Z80)
Den jag började med var en Sinclar ZX-81. Den
hade modiga 1k
ram-minne och en Z80 på 1MHz. Nu var det
så att på den
tiden
så räknade man oftast bitar genom att
titta på databussen
och
CPU:ns interna instruktioner. En Z80 arbetar hela
tiden internt
med 8 bitar. Skulle man behandla större tal
än 255 fick man
alltså "emulera" större
instruktioner genom att göra
alla
sådana operationer i många små
steg, på samma
sätt som man
kan göra multiplikationen 3*3 genom att addera
3 med sig
själv 3 gånger för att få 9.
På samma sätt
får man då använda
sig av 8-bitars instruktioner för att kunna
hantera tal som
ska kunna rymma tal större än 255.
(Rätt ofta, med andra
ord)
Däremot kunde en Z80 adressera upp till 64k
minne (i teorin)
så alla adresspekare var 16-bitars, och
bestod då av två
st.
8-bitars enheter som klumpades ihop. Två 8-
bitars tal kan
peka ut 256*256 olika minnesplatser.
Samtidigt så använde den 8 ledningar (en
8 bitars buss) mot
ram-minnet, för att skicka och hämta
data. Då var det
ingen
tvekan om att den var en 8-bitars CPU. Internt
(instruktionerna)
och externt (databussen) hade dataflödet samma
storlek.
Det fanns en del CPU:er som var 4-bitars, 9-bitars
och andra
märkliga konstruktioner, men de udda 9bitarna
tänkte jag
hoppa över, och de 4-bitars "CPU:er"
som fanns tidigare
skulle
idag närmast klassas som embeddedchip i samma
klass som en binär
räknare (555) eller en vippa. Då de kom
var de säkert
underverk förstås.
- Z80 (ZX-80, ZX-81, ZX Spectrum, C128, Jupiter Ace, TRS-80, MSX m.fl)
- 6502 (PET, VIC20, AppleII)
- 6510 (C-64, C-128?)
- 8086/8 (IBM PC/XT)
Sen vart det ett litet problem med hur man skulle mäta bitarna. En del hade
fortfarande 8-bitar externt, men räknade med 32 internt (68008) medans CPU:er
som 8088:an såg ordentligt 8-bitars ut på insidan, men hade ändå möjlighet att
adressera 20-bitar externt (1024k) Det som jag placerat under kategorin 16-bitars
CPU:er är ju dessa hybrider som var varken det ena eller det andra. Jag stötte
aldrig på någon CPU som jag upplevde som ren 16-bitars. Lagom tills att marketingfolket
får klart för sig hur de skulle använda bitarna i reklam var redan 32-bitar
på marknaden. Undantaget var väl Nintendo och liknande som kände sig tvingade
att kalla sina spelkonsoler för 8,16,32-bitars i olika omgångar, men det var
nog ännu mer marknadsföringsknep och mindre fakta där.
- 68008 (snikversion av 68000, fanns i Sinclair QL bl.a)
- 80186 (Compis, det svenska datorbyggarfiaskot =)
- 80286 (IBM AT)
Det var ju många som ville placera 68000 i 16-bitarsfacket pga. att den hade 16-bitars buss externt, men internt så gick allting i 32-bitars, både för data och adressrymd. Den kunde alltså tro att det satt 4G ram kopplat till den, men eftersom bara 24 ledare från adresspinnarna var tillgängliga på utsidan så gick bara 16M att använda. Programmen var dock "rena 32-bitars" och drog full nytta av att köras på en senare 680x0 med mer än 16M minne. På Intelsidan var det iom 80386 som de tog klivet upp till 32-bitars, i mina ögon. Helt plötsligt kunde man gå ifrån intels märkliga 64k-segment-adressering och gå på rena 32-bitars adresser. Här dök också alla RISC-CPU:er upp, varpå man kunde brottas lite med RISC-vs-CISC när folket tappat förtroendet för det 16-vs-32-gnabb som pågick.
- 68000,68010,68020,68030,68040,68060 (Amiga, Atari, Mac m.fl)
- 80386,80486,Pentium-1,2,3,4 (PC)
- Sparc sun4,sun4c,sun4d,sun4m (Sunmaskiner)
- MIPS R2-3-4-5000 (SGI, Playstation, Pmax m.m)
- PPC 601->G4 (PowerMac, IBMs servrar, PPCamiga =)
- ARM (palm-device:ar)
Här blev det ett "stopp" så att säga. När 386:an kom, så var fortfarande 16M
minne en lyx. Att CPU:n kunde adressera 4G var så oändligt långt bort att man
inte behövde fundera på det ens. MS-DOS lät 386:an gå i gammal x86-mod alldeles
för länge bara för att det inte fanns nåt kundtryck att göra det effektivare
då. Under hela 1985->95 jobbade man sig upp från 4-8-16M till datorer som faktiskt
kunde ha en Gigabyte minne. Då började man närma sig taket för vad de nuvarande
CPU:erna skulle klara av och man fick se sig om efter en ytterligare fördubbling.
Den som följt IDE länge vet ju att man på IDE-fronten normalt sett brukar fyrdubbla
sig fram. Först var det problem med 540M, sen 2G, sen 8G, via 33G och nu anses
IDE-problem-nivån ligga på 137Gb. Men skillnaden mellan att gå från 32-bitars
adressrymd (som klarar 4294967296 bytes, 4G) till 64 innebar att man nu kan
ha 18446744073709551616 bytes adresser, bara 18 miljarders miljarder bytes.
Nu tar det säkert ett tag innan vi fyller upp DET området, men för en maskin
med ett par gig minne så blir det faktiskt trångt om man kör på en 32bitars
CPU. Man brukar inte låta program ligga där de lagras i minnet, utan man låter
MMU:n mappa om från virtuella adresser som programmet ser till riktiga adresser
som operativsystemet ser för att få kontroll (och kunna swappa in och ut m.m.)
så om man närmar sig gränsen för vad CPU:n kan hantera så minskar handlingsfriheten.
Det här bör förklaras i en artikel om virtuellt minne egentligen, det tar för
lång tid för att passa in här. Hursomhelst, att gå till 64-bitar kommer kräva
att man byter CPU för de flesta, vilket innebär att man inte får med sig sina
gamla fina program utan de måste kompileras om. Alla program vinner inte på
att man går från 32->64 bitar, men eftersom många filsystem och liknande delar
av operativ- systemet redan nu använder sig av 64-bitars matematik(på samma
sätt om Z80 fick göra för att räkna tal större än 255) så kommer de delarna
vinna på att CPU:n internt också behandlar data i större enheter.
| Nästa sida » |
Diskutera denna artikeln i vårt forum!