x86-architectuur viert 25ste verjaardag

Vandaag precies een kwart eeuw geleden kwam Intel met een opvolger voor de 8-bits 8080- en 8085-processors. Het bedrijf presenteerde na twee jaar hard werken onder zware druk van concurrent Zilog de 8086, een 16-bits ontwerp met vernieuwde instructieset. Niemand had op dat moment kunnen beseffen hoe belangrijk deze mijlpaal in de geschiedenis van de pc zou zijn. De simpelere variant, de 8088 met 8-bits externe bus, werd door IBM namelijk in de eerste pc gestopt. Verder verkocht Intel licenties op het ontwerp van de chip, waardoor anderen hem dus tegen betaling konden namaken. Het ontwerp werd daardoor ongekend populair, en geschat wordt dan ook dat er ruim 100 miljoen werden verkocht.

Deze populariteit deed Intel er ook toe besluiten om de opvolgers van de chip, waaronder de 80286 en 80386, backwards compatible te houden. De instructieset kwam daarom al snel bekend te staan als x86, en het mag bekend zijn dat deze vandaag de dag nog steeds actief gebruikt en verder doorontwikkeld wordt. In eerste instantie alleen door Intel zelf, maar toen het bedrijf na de 486 besloot dat het uitgeven van ontwerpen afgelopen was, en dus niemand meer letterlijk de Intel-chips na mocht maken, gingen ook anderen aan de slag om x86-compatible chips te ontwerpen. Dit was te hoog gegrepen voor veel kloonbedrijven, maar AMD heeft met de introductie van K7 en K8 aangetoond dat Intel niet de enige is die het lukt om de levensduur van x86 verder uit te rekken. De roep van de markt om compatible te blijven, gecombineerd met een flinke dosis concurrentie, haalt al jaren het allerbeste in de chipontwerpers naar boven. Hierdoor begrijpen de huidige Intel Pentium 4 en AMD Opteron - die onvoorstelbaar veel complexer en sneller zijn dan de 8086 - nog steeds dezelfde taal als deze chip uit 1978.

Hierboven een afbeelding van de core van de Intel 8086. De chip werd gebakken op 3 micron en bevatte 29.000 transistors. Het geheel was beschikbaar op 5, 8 en 10MHz. Het beestje kon 1MB geheugen adresseren. De verdere ontwikkelingen zijn geschiedenis:

Naam

Jaar

Procédé

Transistors

Kloksnelheid

8086

1978

3 micron

29.000

10MHz

80286

1982

1,5 micron

134.000

12MHz

80386

1985

1,5 micron ~ 1 micron

275.000 ~ 855.000

33MHz

80486

1989

1 micron ~ 0,8 micron

1.200.000 ~ 1.600.000

100MHz

Pentium

1993

0,8 micron ~ 0,35 micron

3.100.000 ~ 4.500.000

233MHz

Pentium II

1997

0,35 micron ~ 0,25 micron

7.500.000

450MHz

Pentium III

1999

0,25 micron ~ 0,13 micron

9.500.000 ~ 28.000.000

1,4GHz

Pentium 4

2001

0,18 micron ~ 0,13 micron

42.000.000 ~ 55.000.000

3,06GHz

Lees meer bij Heise.

Reacties (109)

Ik heb altijd gedacht dat hier het bewijs werd geleverd voor de stelling (van Cruijf) dat je zwakte ook je sterkte kan zijn. NL: Intel was in financiële moeilijkheden geraakt door de dumping praktijken van de japanners op het gebied van geheugenchips. Toenertijd waren geheugenchips de belangrijkste inkomstenbron voor Intel. Dus Intel besloot om snel op zoek te gaan naar nieuwe inkomstenbronnen en dat zou dan o.a. van de afdeling Microprocessoren moeten komen. Aangezien Intel deze inkomsten snel nog had (anders dreigde faillissement) kwam Intel met een omgevoerde 8080 (8 bit) processor, de 8086/88 , een 16 processor. Voordeel voor de gebruiker: met een special conversieprogje kon 8080 programmaatje laten draaien op een die 16bit processor. Dus snelle marktacceptatie dus snel inkomsten. Motorola was toentertijd financieel zeel sterk dus kwam met een echt 32bit proc. Maar de yield bij de produktie in eerste instantie was zeer laag (zeer veel meer transistoren werden gebruikt). Dus grote aantalen konden niet geproduceerd worden. En dit was voor de toenmalige ontwikkelaars van de IBM PC de reden om de 68000 proc niet te gebruiken. Want ook IBM zag in dat dit de laatste kans (na vele mislukte pogingen) was om succesvol zijn in PC markt. Men moest zeker snel grote aantallen kunnen om een substantieel marktaandeel te verwerven!

<font color=#786562>* |aKra| pinkt een traantje weg
</font>
Dat je kijkt in wat voor `n luxe we dus nu leven vergeleken met toen, en dan willen we nog verder, en is het NOG langzaam... Zoals iedereen dus nu overclockt (wat ook meer redenen heeft natuurlijk!).

(En dat je vroeger 10MHz overklokte en je was de man, en tegenwoordig moet je al gauw 500MHz+ overklokken voordat het 'echt' wat is...)

om die chips te overclocken zou je de klokgenerator moeten vervangen, dat ging nog niet met het BIOS
Zo'n klokgenerator is (of dat nu nog zo is weet ik niet zeker) eigenlijk gewoon hetzelfde als een kristal zoals ook in (bijvoorbeeld 27 MHZ) zenders wordt gebruikt, is technisch dus wel mogelijk, en ik meen dat sommige mensen dit wel deden met de 286 en 386. Maar in die tijd kon je ook enorm veel prestatiewinst boeken door je systeem optimaal samen te stellen en je geheugen optimaal te laten gebruiken DMV je config.sys (vanaf de 286 in beperkte mate, de 386 volledig). Ik heb ooit een goedkoop 286 moederbord gekocht op de HCC beurs waar dus geen jumpers op zaten en geen handleiding bij zat. Twee weekenden aan het klungelen geweest om alles aan de praat te krijgen, maar toen kon ik wel (blut als ik was) Wolfenstein 3D spelen op mijn 14" paperwhite VGA ....
Dat waren de tijden, toen moest je nog een beetje snappen waar je mee bezig was, anders werkte het nooit en te nimmer niet.
Met de Pentium (en high end 486 toen ook al AMD die een DX4100mhz uitbracht) met win95 kwam ook plug and play, wat in het begin zo goed werkte dat het spottend plug and pray werd genoemd. Toen scholden we dat dus wel helemaal verrot, want als zo'n p&p kaart niet tof werkte, had je dus helmaal geen jumpers meer om alles zelf in te stellen, hoe konden ze dat maken nietwaar ?

Om je PC te tweaken zette je er een NEC cpu in, en was je dagen bezig om de optimale interleave voor je MFM-schijven te vinden. 80% van de computers hadden een 20Mb Seagate ST-225..

zucht.. the good old days..

hezik is oud

Ach, ik ben 18 en heb die 20MB schijven en bijbehorende computers ook nog gezien. Weliswaar waren ze toen oude bakken, maar kennen doe ik ze ook nog.

'k Ben dus eigenlijk een tweaker van 40486. Betere aanduiding voor je geboortejaar dan zo'n stomme datum vanaf de geboorte van een of andere illusionist.

Ik ben ook 18, maar mijn eerste spelletjes speelde ik op een 8086, en later een 80386, omdat anders sommige 32-bit spellen het niet deden Toen we die kregen, was die nog tamelijk nieuw.

Ik ben van één a.8. (anno 8086)

(En dat je vroeger 10MHz overklokte en je was de man, en tegenwoordig moet je al gauw 500MHz+ overklokken voordat het 'echt' wat is...)

Bij de 8086 was 10 MHz ook een 100% overclock, tegenwoordig is dat nog niet eens 1%

Mijn eerste overklok ervaring:

Ik liet een DX2-66 80486 processor van Intel lopen op de AMD instelling voor de DX2-80. Hij liep dus op 80 Mhz en ik was de held van de buurt met de snelste computer.

Later een DX4-100 upgrade gekocht en deze op 120 Mhz laten draaien. Ge-wel-dig. Ik was trouwens ook de enige die wel 20 Mb in zijn computer had (4x1 en 4x4 simm).

Waar ik nu echt benieuwd naar ben is de opvolger van de x86-architectuur. En helemaal naar of dat deze van Intel of van AMD af komt. AMD heeft de afgelopen jaren zoveel progressie geboekt op alle fronten dat ze inprinciepe instaat moeten zijn om een nieuwe architectuur te ontwikkelen. et is alleen de vraag of Intel ze niet voor is.

Ik dacht dat de itanium een geheel nieuwe architectuur was. Dus van niets uit opnieuw gebouwd is door Intel of heb ik dit mis?

Klopt. De Itanium gebruikt de IA-64 architectuur, terwijl de Opteron x86-64 gebruikt. Voordeel van de Opteron is dus dat het x86 lekker vlot kan uitvoeren, terwijl de Itanium x86 moet emuleren, en dat heel sloom doet (alhoewel Intel daar alweer wat op gevonden schijnt te hebben).

Jaha, dat kan wel zo zijn, alleen moet een software boer zoals M$ het wel gaan gebruiken.... wat je dan gaat krijgen is dat je weer met verschillende standaarden gaat werken... iets waar we dus niet op zitten te wachten met zijn allen. dus, laat het maar lekker zoals het is nu, natuurlijk wel met de nodige vooruitgangen etc etc, maar laten ze aub één standaard blijven hanteren!

Ze zullen sowieso van de CISC structuur af moeten. In de huidige x86 processors wordt de CISC instructie al vertaald naar RISC, uitgevoerd en terugvertaald. Dat blijkt sneller te zijn dan native CISC...

Maar eh... Proficiat!

De 8086 heeft het eigenlijk maar op het nippertje gehaald, en was zeker niet de beste "microcontroller" op de markt. Toen IBM het plan opvatte om een eigen pc op de markt te brengen, hadden ze geen tijd om nog even snel een processor te ontwerpen. IBM's eigen ingenieurs wilden eerst de superieure Motorola 68000 gebruiken, en die werd later in de vergeten IBM Instruments 9000 Laboratory Computer gebruikt. Jammer genoeg had IBM reeds de rechten om de 8086 te fabriceren van Intel verkregen... (in ruil voor het eveneens vergeten "Bubble Memory") Wat zou alles anders gelopen zijn...

Klopt. Maar moeten wij daardoor in school nog altijd met die 68000 werken en de instructieset ervan leren gebruiken? Nah, ik heb er genoeg van. Onze microcomputer die we moesten bouwen met de 68000 werkt nu op 8MHz, wat heb ik daar nu aan? Goed voor rekenmachines.

Mijn leraars hebben allemaal een beetje heimwee naar hun tijd met Motorola denk ik. Ook al was die beter en eenvoudiger, nu zijn we er bijna niets meer mee. We leren er wel de basics van cpu's mee.

Voor educatieve doeleinden kun je denk ik toch beter een simpelere processor gebruiken die door 1 iemand volledig te leren is. Als je nu met P4's gaat werken, dan krijg je bijna onmogelijk het hele plaatje van wat de processor nou helemaal doet voor je, en zullen principes je ook veel minder gauw duidelijk worden.

Zelfde met besturingssystemen. Een besturingssysteem kan wel in een hedendaagse computer passen, maar bijvoorbeeld Linux of Windows XP zijn niet binnen afzienbare tijd geheel door een mens te beheersen. Een simpeler maar volledig OS als Minix kan dat wel, en is dus een stuk geschikter voor educatie.

En daarnaast, als je de principes eenmaal doorhebt, is de overgang naar een ander ontwerp of platform niet moeilijk.

Sibbe, volgens mij realiseer je je niet hoeveel embedded systemen een 68000 of afgeleide bevatten. Die dingen zaten werkelijk overal in, wasmachines, magnetrons, LCD-displays in stadions, etc. De 68000 is altijd belangrijk gebleven.

Prive ben ik begonnen met 6510 (=6502) assembler te leren. Daarna heel veel 68000 assembler geprogrammeerd.
Op de opleiding kennis gemaakt met IA32 en prakticum assistent voor de 8085 assembler geworden.

Uit deze ervaring kan ik je verklappen dat je heel erg blij moet zijn dat er bij jullie opleiding gekozen is voor de 68000 om de basics van een proc te leren....

In elk boek over netwerken, wordt dit uitgelegd aan de hand van de OSI standaard. Deze standaard is zelden geimplementeerd en wordt nu nergens gebruikt (bij mijn weten). De uiteindelijk winnaar in de markt heeft natuurlijk het gelijk van de massa, maar hoeft theoretisch niet de beste te zijn. Voor een opleiding moet het bij voorkeur ook nog simpel zijn, dus daarom 68000 ipv RISC/x86 OSI ipv TCP/IP.

Ik kan me vergissen, maar volgens mij haal je wat door elkaar. Het OSI model is een manier waarop computers met elkaar communiceren. Ze doen dat via verschillende (7) lagen met onderin de hardware laag en bovenin de applicatie. TCP/IP zitten hier op laag 4 en 5 geloof ik.
https://secure.linuxports.com/howto/intro_to_networking/c4412.htm

(hoe krijgen jullie toch altijd zo'n lange link in een hyperlink??? )

OSI is een model, TCP/IP is een protocolstack. Daar zit het verschil, en TCP/IP zit niet in OSI, maar bestaat ernaast, en bevat 5 lagen, waarvan er off the top of my head 3 overeenkomen met lagen uit het OSI-model.

Het grote argument voor BigBlue om de 8088 te gebruiken was CP/M. Let wel toen de PC werd ontwikkeld bestond MS nog maar net.

IBM heeft bij de makers van CP/M (Digital Research) aangeklopt met de vraag of men CP/M wilde porteren naar het 8086 platform. Men had ingezien dat dit niet kon met een compleet andere instructie set dan de 8080. Daarom is de 8088 gekozen. DR heeft van de deal afgezien omdat men meer geloof in de 8080 had. Dat was immers ruimschoots door de markt geacepteerd en was Zilog bezig met de Z800. Een snellere variant van de Z80, die op zijn beurt weer 100% upwards compatible was met de 8080. Men zag in het Zilog verhaal een natuurlijke groei.

Een directe afgeleide van dit stukje verkeerde politiek was dat een ex-directeur van DR nu nog steeds zo tegen MS is. Wie was dat dan wel, Martin Healey, die zeikerd van de computable. Hij is uitermate gefrustreerd dat een university-dropout rijker is dan meneer de professor zelf.....

Het probleem van een nieuwe architectuur is dat het qua besturingssystemen niet backwards compattible is.
Dus stel dat de p5 een andere architectuur heefd kan je er alleen Longhorn op draaien. En als je dat niet fijn vind kan je er niet ff XP/2000 op zetten.

En over de Itaniums: Ik d8 dat Windows Server 2003 er support voor levert of heb ik dat fout?

Och, Linux draait op 15 architecturen en Debian heeft software voor 11 (12) ervan... Genoeg keuze Windows is irrelevant

Serieus, het wordt tijd dat AMD/Intel die backwards compatibility eens volledig afschudden, want er worden kosten gemaakt voor iets wat over een jaar of wat niet meer relevant is.

Denk maar eens terug hoe snel het ging toen Windows 95 uitgegeven werd hoe snel Windows 3.1 programma's werden herschreven voor de nieuwe API. Binnen een jaar waren in ieder geval al mijn Win3.1-progjes de deur uit en vervangen door Win95-varianten/versies.

Denk maar eens terug hoe snel het ging toen Windows 95 uitgegeven werd hoe snel Windows 3.1 programma's werden herschreven voor de nieuwe API.

Denk maar eens terug hoe snel het ging toen de i386 in 1985 uitgegeven werd, en hoe snel alle 16-bits applicaties werden geport naar 32-bits! Het duurde tien jaar voordat de consument een semi-32bits OS had (win95), en nog eens zeven jaar voordat de consument standaard een volledig 32-bits OS kreeg bij zijn PC(winXP)! ZEVENTIEN jaar in totaal dus!

In de tijd van Win3.1 was er vraag naar een beter OS, en die vraag werd (gedeeltelijk maar afdoende) opgevuld met Windows 95. In 1985 zat niemand op een 32-bits proc te wachten, en nu ook zit Jan Modaal niet op een 64-bits proc te wachten. Het belangrijkste bij de aankoop van een consumenten-pc is de prijs en de compatibiliteit met de buurman. Net als halverwege de jaren '80 toen je je 286-spelletjes natuurlijk nog wel moest kunnen draaien op je fonkelnieuwe 386.

een volledig 32-bits OS was er al in 1996 hoor: het ging de markt in onder de naam Windows NT 4.0. En er was ook een workstation-versie van.

Ok, hij kon 16-bits applicaties draaien (maar 2000/XP/2003 kunnen dat ook) maar dan wel in een VM en niet in real-mode zoals in Windows 9x/Me.

zolang de consument nog met windows 95/98 kan tekstverwerken, MSN'en en mp3tjes luisteren vinden de meeste het wel best.

Welke nieuwe PC van tegenwoordig biedt buiten spellen en uitgebreide videoediting nog voordelen boven een PC van een jaar geleden? Of misschien zelfs 2 jaar.

een volledig 32-bits OS was er al in 1996 hoor

Bijna goed. Daarvoor was er al de Amiga 3000. Een 32bits machine met 32bits AmigaOS.

lezen... ik had het over Jan Modaal, ofwel de consument. En gebruikte die Win NT? Nee. En zorgt die voor commercieel succes van een patform? Ja.

Ik zat er nog over te denken om die woorden vet neer te zetten, maar dat komt ook zo schreeuwerig over....

Het duurde tien jaar voordat de consument een semi-32bits OS had

De consument dus, Jan Modaal komt pas in je stukje over 64-bits CPU's. En laten bedrijven nu technisch gezien ook consumenten zijn

saintnighmare:
so true, alleen een klein detail: de Amiga 3000 was geen x86

Bijna goed. Daarvoor was er al de Amiga 3000

En daarvoor was er al AmigaOS die volledig 32 bits was vanaf het prille begin (1985) Als frappante uitzondering moet ik de bijgeleverde M$ Basic interpreter noemen, die was zoals we van ze gewend zijn halfgaar gecodeerd en gebruikte de bovenste 8 bits voor zichzelf (omdat de eerste Amigas met 68000 een 24 bits adresbus hadden en dat op dat moment geen conflict opleverde, maar desondanks wel tegen de officiële C= Style Guide in ging), maar dat was dan ook geen onderdeel van het OS zelf.

Overigens waren er voor dat de Amiga 3000 (met 68030) uitkwam al (peperdure) 68020/68030 kaartjes te krijgen voor de Amiga 2000 en voor zover ik weet was de 68020 al volledig 32 bits.

Amiga

Ja, die overgang van 3.1(1) naar 95 was echt razend snel, maar toen was de gebruikersbasis ook nog relatief klein. Nu zie je toch nog veel mensen 98(SE) en ME gebruiken, terwijl XP al een poos op de markt is. maar ook dat tijdperk komt ten einde (gelukkig)

dat zou je denken... maar het grootste gedeelte van de windowsgebruikers wereldwijd gebruikt windows95 en niet een latere versie.

je kan ook met fases werken, zoals amd nu doet met de opteron/athlon64..eerst supporten ze zowel 32bit als 64..later zal er meer gefocust worden op 64bit en zal 32bit langzaam aan verdwijnen

Is dit niet de reden waarom het 16/32 Bits besturingssysteem Windows 95/98/ME zo instabiel wordt bij het draaien van 16 Bits programma's ?

De architectuur wordt in de toekomst niet meer relevant daar applicaties niet meer rechtstreeks de instructieset van processoren zullen aanspreken. Dit vanwege de ontwikkeling van 'virtual machines' zoals .NET CLR & Java. Hierdoor zullen de architecten van processoren volkomen vrij zijn. Zorg als processormaker voor een 'virtual machine' en viola iedere (.NET CLR of JAVA) applicatie kan (zij het indirect) draaien op jouw processor!

Dat is toch al jaren zo? De meeste applicaties spreken niet direct de CPU aan, maar de API's van windows/linux. Daar heb je geen .net voor nodig hoor... als er maar een windows/linux is voor jouw CPU..

Hij bedoelt bij run time en jij bij compile time. Dat is nogal een verschil.

Voorbeeld: Een app voor Linux/x86 kan je niet 1-2-3 op Linux/sparc uitvoeren. Dat zal je opnieuw moeten compilen. 'Als het goed is' (wat het zelden is in de praktijk) zou je geen veranderingen aan hoeven brengen in de source.

Bij java hoef je niet opnieuw te compilen. De java bytecode wordt aan de VM gevoerd, die het vervolgens vertaalt naar bytecode voor het bewuste systeem, en het uitvoert. Nadeel is dus dat het veel trager is om op deze manier dingen te doen.

Het is niet veel trager. Zeker in het verleden waren er nogal eens compilers die niet naar opcodes, maar naar C code compileerden. Daarna moest die code dan met een standaard C compiler gecompileerd worden naar het uiteindelijke hardware-platform.

TaalX -> C -> hardware opcodes

Was niet echt beduidend trager (enkele procenten).

Wat je nu hebt met Java is dat een JIT compiler java byte code on-the-fly compileert naar native opcodes.

Java -> Java byte code -> hardware opcodes

Ook niet echt beduidend veel trager.

Maar de vraag is hoe snel. Zonder tussenstap zal het altijd sneller blijven gaan en dus zullen programmeurs van vele applicaties altijd proberen bij de instructieset te blijven.

Anders zouden er inmiddels ook wel virtual machines voor GPU's zijn, denk je niet...

Hoe vreemd het misschien ook klinkt, maar dat hoeft neit zo te zijn. Een just in time compiler kan soms beter optimaliseren naar de heersende omstandigheden dan een 'normale' compiler. Als hierbij de winst groter is dan de kosten van het compileren is de JIT methode sneller.

Het lijkt wat tegenstrijdig, maar je zou het een beetje kunnen vergelijken met stacker/drivespace van vroeger. Door het (de)comprimeren zou de IO acties langzamer moeten zijn, maar op een gegeven moment waren de CPU's zo snel dat die kosten minder waren dan de winst die werd behaald doordat er minder data van de trage HD gelezen hoefde te worden. Stacker/drivespac gebruiken bleek je IO snelheid juist te verhogen!

Veel veranderingen of doorbraken hebben niets met techniek te maken. Als dat wel zo was had iedereen eenV2000 vcr gebruikt ipv VHS, een Mac ipv een DOS-box, en linux ipv windows.

Boven techniek staan altijd nog het kostenplaatje en marketing. In dit geval wil dat zeggen dat veel bedrijven het erg fijn zullen vinden dat hun software op alle mogelijke hardwareplatformen kan draaien (onthoud even dat 90% van alle software 'zelf' ontwikkeld wordt).

Een bedrijf wat alles op java heeft draaien kan iedere x jaar dat de hardware geupgrade moet worden kiezen op welk hardware platform ze zullen gaan draaien. Dit bespaart ernstig veel op de kosten.

Wat fschuls zegt gaat op voor het merendeel van alle gevallen; het is zeker geen BS. Je vriendjes op de vakgroep bekijken het alleen vanuit de technische hoek.

.net applicaties worden door de compiler omgezet naar meta-code, deze beschrijft de werkelijke code. Vervolgens als de gebruiker op het doelsysteem de applicatie start dan wordt deze gecompileerd door een meegeleverde compiler. Omdat deze meta-code krijgt aangevoerd is dit proces snel klaar waarna de machine code volledig geoptimaliseerd is voor het betreffende systeem en de applicatie start op.

En voor het gemak is de 80186 vergeten :

1982 : 80186 - 10 Mhz

In hetzelfde jaar kwam de 80286 uit en er zijn maar erg weinig PC's met deze CPU.

en vergeet dan ook met1 de pentium Pro niet.

Sommigen beweren dat dit de meest efficiente x386 chip ooit was.

Dat was de P6 core waar later ook weer de Pentium3 op gebaseerd is. Dus zal er zeker een groot voordeel aan gekleefd hebben.

Nadeel was dat hij in 16-bits mode langzaam werkte, en ten tijde van de PPro was er nog veel 16-bits software.

de p2 was er ook op gebasserd, alleen liep bij de p2 de l2 cache maar op halfspeed, en bij de p3 liep die wel op full speed, net zoals de l2 cache bij de p pro deed.

Nou ja zeg!
Ik gebruik nog regelmatig een 80186.
In m'n synth welteverstaan.

Maar dankzij Intel zitten we dus nog steeds vast aan die beperking van IRQs. Dat irritante gedoe tussen IO poorten en memory mapped IO. Het switchen tussen geheugenbanken en de verschillende modes waarin je kunt draaien van je CPU.
Tevens een van de meest inefficiente lijn van processoren ooit. (let even op de onderbouwing)
De processoren van bijv. Alpha, Sun, IBM en motorola hebben keer op keer bewezen dat zijn sneller en betrouwbaarder waren. (moet je wel CPU's van dezelfde jaartallen vergelijken).

Maar dankzij Intel zitten we dus nog steeds vast aan die beperking van IRQs.

x86's kunnen altijd al 256 IRQ's aan. Alleen de interrupt controller die in de eerste PC's werd gebruikt kon er maar 8 gebruiken, en later in de AT's werd er een tweede bijgezet waardoor het totaal op 16 kwam. Dat heeft niks met Intel te maken, maar met compatibiliteit met de IBM PC.

(PC's met een APIC kunnen ze gewoon alle 256 gebruiken)

Dat irritante gedoe tussen IO poorten en memory mapped IO.

Wat is er irritant?

Het switchen tussen geheugenbanken

Vanuit protected mode kun je al vanaf de 286 gewoon rechtstreeks al het geheugen adresseren. 'Switchen tussen geheugenbanken' is alleen iets wat bij EMS gebruikt werd, en dat wordt al *lang* niet meer gebruikt.

en de verschillende modes waarin je kunt draaien van je CPU.

Ik zie niet hoe het ondersteunen van meerdere modi een beperking is eerlijk gezegd. Als je protected mode handig vindt (en wie vindt dat niet?) gebruik je gewoon alleen protected mode.

En dat je 80186 dat niet aankan.. tsja.. had je maar een synth met een andere cpu moeten kopen. Intel cpu's zijn dat stadium in elk geval al lang voorbij.

Het is wel zo dat het aantal transistors vaak ietwat vertekend is, doordat de transistors van de on-die caches ook meegeteld worden. Dat tikt gauw aan.

Men telt gewoon het aantal transistors dat in de chip zit. Wet van Moore zegt dat de transistors om de 18 maanden verdubbelt.

Snap ik, maar verdubbeling van cache laat het aantal transistors omhoog schieten, terwijl de mogelijkheden van de core eigenlijk ongewijzigd blijven. Een cache "doet" ook niets, voert geen bewerkingen uit.

De CPU-core zonder cache telt een pak minder transistors, maar om aan Wet van Moore te voldoen en marketingredenen kiest men toch voor de grootste getallen. Dus men telt alle transistors (ook van de cache), doet mij denken aan de Watten van audio-apparatuur. De echte vermogen van een versterker is bv 100Wrms met 0,1% THD bij 100-20000Hz, dan durft men dat te verkopen met 200Wmusic of 10000Wpmpo, getallen vergroten...

Pentium Pro heeft 5500000 transistors als je 2 x 8 KB L1 Cache meerekend.
Er komen 15500000 transistors bij voor 256 KB L2 Cache of 31000000 transistors extra voor 512 KB L2 Cache of 62000000 transistors extra voor 1 MB L2 Cache.

Snap ik, maar verdubbeling van cache laat het aantal transistors omhoog schieten, terwijl de mogelijkheden van de core eigenlijk ongewijzigd blijven. Een cache "doet" ook niets, voert geen bewerkingen uit.

Plaatje van de voorloper van de x86:

ftp://download.intel.com/intel/intelis/Museum/exhibit/hist_micro/hof/l arge_jpegs/4004B.JPG

Wat mij niet geheel duidelijk is, is of er ernstige nadelen kleven aan de x86-architectuur. M.a.w. is het niet zinnig om toch een soort upgrade uit te voeren, of is x86 zo flexibel en goed bedacht, dat het voor altijd gebruikt zal worden?

X86 is totaal inefficiënt, zelfs zo inefficient dat de x86 code word omgezet naar risc en later weer terugvertaald naar x86.

vandaar dat een Mac ook meer vermogen uit een Mhz kan persen.

Je trekt hier volkomen verkeerde conclusies uit het RISC vs CISC verhaal. Beiden hebben hun voor en nadelen. De hard praktijk is dat beiden streven naar een gulden middenweg.

En alles bij elkaar is x86 toch nog sneller. Dan kunnen ze het honderd keer vertalen, het blijft sneller dan de Mac.

x86-architectuur viert 25ste verjaardag

Dan zitten we al weer 20 jaar te wachten op de volgende revolutie in PC architectuur.

20 jaar wachten? Had je niet wat leuks/nuttigs kunnen doen in die tijd.