x86-instructieset viert dertigste verjaardag

Tijd voor een feestje

Zondag 8 juni is het precies dertig jaar geleden dat Intel de 8086 introduceerde, de eerste van de lange serie microprocessors die vandaag de dag vrijwel overal te vinden is. Genoeg reden om terug te blikken op dit invloedrijke stukje techniek.

De 8086 was de eerste echte 16-bits processor van Intel en ook de eerste die een hele megabyte geheugen kon aanspreken. Weliswaar alleen in blokken van 64KB, maar dat was nog steeds een flinke stap voorwaarts ten opzichte van zijn 8-bits voorgangers, die maar met één zo'n blok konden werken.

De 33mm² grote chip bevatte 29.000 transistors en werd gebakken met een 3200nm-procedé. De processor werkte op een spanning van 5V en had een maximaal verbruik van 2,5W. Het socket had veertig pinnen en de oorspronkelijke kloksnelheid was 5MHz. Latere versies gebruikten iets geavanceerdere productietechnieken om 8MHz en 10MHz te halen.

De 8086 was lang niet de eerste processor en had net als veel van zijn concurrenten kunnen eindigen als voetnoot in een technische handleiding. Kent iemand de National Semiconductor IMP-16 nog? Of de Texas Instruments TMS9900? De enige reden dat we de Intel 8086 herdenken en de anderen niet is omdat software geschreven voor de 8086 dertig jaar later nog steeds kan draaien op de nieuwste servers, desktops en notebooks. En de kans bestaat dat dit over dertig jaar nog steeds het geval is.

De oorsprong van x86

De instructieset van de 8086 bestaat uit ruim honderd verschillende opdrachten die grotendeels gebaseerd zijn op die van de 8080, die op zijn beurt weer gebaseerd was op de 8008. Geen van de chips was echter compatibel met elkaar. De assembleercode was relatief eenvoudig en soms deels automatisch te converteren, maar een 'gewone' gebruiker maakte geen schijn van kans om zijn oude software op een nieuw systeem te gebruiken.

De oorspronkelijke instructieset was overigens niet eens bedacht door Intel zelf, maar door Computer Terminal Corporation. Dit bedrijf wilde begin jaren zeventig een product gaan bouwen dat al veel op een desktop leek. De 8008 liep echter vertraging op en presteerde onder de maat, waardoor CTC hem nooit gebruikt heeft. Intel heeft hem toen nog wel op de markt gebracht, maar echt populair zou het als 'beperkt' en 'onhandig' omschreven ontwerp nooit worden.

De in 1974 uitgebrachte 8080 was een verbeterde versie van de 8008 en wordt door Intel gezien als de eerste 'echte' microprocessor. Vanaf die tijd begon het concept van de desktopcomputer ook steeds serieuzere vormen aan te nemen. Intel wist Altair ervan te overtuigen om de 8080 te gebruiken en trok de interesse van meer programmeurs, waaronder een 19-jarige Bill Gates.

Een tijdelijke oplossing - niet dus

Intel had geen intentie om nog veel verder te gaan met de instructieset van CTC. Het werkte koortsig aan de iAPX 432, een ambitieus ontwerp dat weer met een schone lei begon en rekening hield met allerlei 'moderne' concepten, zoals volledige 32-bits verwerking, multiprocessing, garbage collection, virtueel geheugen en 'capability based addressing'. Zaken die tot dan toe in het hart van de software werden geregeld wilde men de hardware in trekken.

Hoewel men vlak na het uitbrengen van de 8080 al was begonnen met dit project, was het zo complex dat een tussenoplossing moest komen. De concurrentie was immers talrijk en zou niet zes jaar lang stil blijven zitten (zo lang had Intel uiteindelijk nodig om het nieuwe 'superontwerp' af te krijgen). Daar kwam de 8086 dus in beeld: als tijdelijke prestatieverhoging tot de iAPX 432 de wereld kon gaan veroveren.

De 8086 was een redelijke haastklus; hij werd in slechts twee jaar tijd uit de grond gestampt. Ondanks de relatief kleine investering van Intels kant werd de chip een enorm succes. Verschillende bedrijven kozen de chip voor hun computers, waaronder Wang, Mycron en AT&T, maar de allerbelangrijkste deal die Intel sloot was die met IBM, dat een goedkopere afgeleide van de chip (de 8088) voor zijn personal computer wilde gebruiken. De pc die binnen de kortste keren eindeloos gekloond werd.

Langzaam werd duidelijk dat de iAPX 432 een flop zou worden. Deels omdat hij te duur, te laat en te traag was, maar ook deels omdat klanten gewend raakten aan computers die dezelfde taal spraken. 'IBM PC Compatible' werd een fenomeen waar de nieuwe chip niet aan mee kon doen.

De pc werd zo groot dat Intel hoe dan ook aan boord van het schip wilde blijven. Het had echter geen poot om op te staan als het ging om een wijziging van de architectuur. Het reusachtige IBM wilde niet afhankelijk zijn van de grillen van een klein chipbedrijfje. Daarom had het afgedwongen dat Intel zijn 8086-ontwerp aan een klein dozijn andere bedrijven moest geven, waaronder NEC, Siemens, Texas Instruments, AMD en Fujitsu.

Als ze er zelf niet meer verder mee zouden gaan, dan zou een van de concurrenten het wel doen. Hierdoor moest de 80286 bijna wel worden ontwikkeld, met extra features en instructies voor nieuwe programmatuur die het kon gebruiken, maar die wel oude 8086-software zonder enige aanpassing moest kunnen draaien. Zo werd x86 geboren, en zo werkt het vandaag nog steeds.

Machtsstrijd

IBM had zichzelf in eerste instantie in een machtige positie gewerkt door standaarden af te dwingen, maar uiteindelijk kreeg Intel hierdoor weer de overhand. Klonen vormden een steeds groter deel van de computermarkt en dat gaf Intel genoeg vertrouwen om dingen op zijn eigen manier te doen. Het ontwerp van in 1986 uitgebrachte 80386 werd dan ook niet meer afgegeven aan derde partijen. Sommigen van hen - waaronder AMD - kopieerden het toch, met jarenlange rechtszaken tot gevolg.

Uiteindelijk oordeelde de rechter in 1991 dat het klonen was toegestaan, maar door met het patentwapen te dreigen wist Intel het overnemen van zijn ontwerpen alsnog te stoppen en daarmee de meeste concurrentie op het gebied van x86-chips effectief uit te schakelen. Slechts een paar bedrijven slaagden erin om op eigen kracht een ontwerp in elkaar te zetten. AMD is daarvan nog steeds de grootste en meest invloedrijke.

Verzet is zinloos?

Er werd - en wordt - soms behoorlijk neerbuigend gedaan over x86. Het is zeker waar dat het de standaard is geworden door een chaotische samenloop van omstandigheden en niet vanwege de mooie architectuur. Veel concurrenten - en af en toe ook takken binnen Intel zelf - denken het dan ook beter te kunnen doen.

Vrijwel iedereen zette in de jaren tachtig in op risc, een ontwerpfilosofie voor chips waarin de complexiteit van cisc in het algemeen en x86 specifiek wordt vermeden. Zo ongeveer alle alternatieve architecturen die nog bestaan komen uit die periode, waaronder Sparc, Power, Mips en Arm. Intel werd hier zo zenuwachtig van dat het zijn eigen risc-chip ontwikkelde, de i860. Deze werd geen succes, in tegenstelling tot sommige andere varianten.

In embedded systemen, gameconsoles en een kleine tien procent van de servers zijn risc-chips nog goed vertegenwoordigd, maar vrijwel alle notebooks, desktops, workstations en goedkopere servers werken op basis van x86-processors, terwijl het steeds kleinere apparaten en steeds zwaardere servers op het oog heeft.

Intel is - na de iAPX 432 en i860 - nog een derde keer met een schone lei begonnen. De samen met HP ontwikkelde Itanium vormt voorlopig echter ook nog geen enkele bedreiging voor de dominante positie van de instructieset die is voortgevloeid uit de 8086.

Dit is het verschil tussen theorie en praktijk: x86 mag dan wel een aan elkaar gehechte bende van dertig jaar 'legacy' zijn, maar zo lang er de meeste software voor is, de beste compilers en het grootste budget voor de knapste ontwerpers en de beste fabrieken, maken nieuwkomers zelfs met de beste 'schone' ideeën nog geen schijn van kans. Dit systeem houdt zichzelf al decennia in stand en dat zal waarschijnlijk nog lang zo blijven.

Reacties (87)

[SCRAP]

Misschien leuk om te vermelden, Microsoft heeft haar Windows NT (New Technology) ontwikkeld op en voor de Intel i860 processor. Een CPU/'GPU' combo uit 1988 die zijn tijd in vergelijking met de x86 van die tijd ver vooruit was. Toen kort erna de i860 serie niet zo'n succes bleek te zijn, heeft Microsoft de code overgezet naar de MiPS en x86 instructieset. Aanvankelijk dacht ook Microsoft, en dat is zeker voor dat bedrijf best opmerkelijk, dat het tijd werd om de x86 architectuur en het 'bijbehorende' MSDos besturingssysteem te vervangen door iets nieuws. Echter heeft MS mede door de flop van de i860 toch nog om de zelfde reden als Intel, voortgeborduurd op de x86/MSdos combo. Jaren later is WinNT pas compatibel gemaakt met MSdos/Win95/98/Me.

Erg jammer dat we dankzij de krampachtige terugwaartse compabiliteit nog altijd vasthouden aan een instructieset die rechtstreeks uit de jaren 70 stamt. Dit hindert de ontwikkeling van onze pc's en bijbehorende chips enorm. Constant moeten de ontwerpers via omwegen en hindernissen, rekeninghoudend met 30 jaar oude instructies en chips, met een verbeterd, sneller chipontwerp op de proppen komen. Als je de uit 1981 stammende iAPX 432 en de uit 1988 stammende i860 onder de loep neemt en inziet waar deze chips toen al toe in staat waren, dan kan je alleen maar dromen over de gigantische voorsprong die we hadden kunnen hebben als deze architecturen 20 tot 25 jaar hadden kunnen rijpen. Moet je je eens voorstellen wat er mogelijk was geweest qua CPU kracht en qua instructieset als we deze x86 handicap niet hadden.

Aan de andere kant vind ik het ook wel fascinerend om te beseffen dat de code geschreven op en voor een 1978 Intel 8086, zonder aanpassingen en of emulatoren kan draaien op een hypermoderne nog niet eens geintroduceerde Intel Nehalem. Dat ik op m'n Core 2 in feite MSDos 1.0 kan installeren en laten draaien... Vreemd genoeg heeft Apple deze stap in haar evolutie wel (succesvol) kunnen en durven zetten met de overgang naar MacOs X, en van Motorola 680xx naar PowerPC, van PwPC naar Intel x86.............. Bizar eigenlijk dat Apple in zekere zin een stap terug doet in de computerevolutie door over te stappen op de zoals gezegd 30 jaar oude x86 instructieset. De een probeert er zonder succes met man en macht vanaf te komen, de ander heeft deze beperking niet en omarmt deze handicap vrijwillig.....

[M2XzeeD]

De reden waarom Apple is overgestapt naar Intel was vanwege de performance per Watt die op x86 processors de komende jaren veruit de beste is.

Echter, met aanstaande overgang van carbon naar Cocoa-64 apps maakt het voor Apple straks niet meer uit welke chip er in zit omdat software dan voor nieuwe chips gecompiled kan worden en een overstap naar een nieuwe architectuur gemaakt kan worden zonder grote problemen.

Echter, zolang windows geen andere architecturen ondersteunt blijft Apple vanwege bootcamp ook op x86 hangen voorlopig. Als Microsoft besluit de volgende windows versie niet meer backwards compatible te maken is de weg vrij voor nieuwe, efficiëntere architecturen. Dat gaat vanzelf een keer gebeuren want er komt een moment dat de rek uit de x86 chips is voor verdere ontwikkeling.

[Romke]

Apple heeft echt niet voor x86 gekozen om Windows te kunnen ondersteunen lijkt me.
De meeste gebruikers van hun hardware zullen toch OS X draaien.
Ik vind het zelf wel prettig als OS X gebruiker, want windows is een noodzakelijk kwaad binnen mijn opleiding.

OS X is altijd al compatible geweest met meerdere architecturen.
Waarom zou Apple zoiets wel kunnen en MS niet? Net als Rosetta, kun je je PPC apps op je Intel mac draaien. Echt snel zullen ze niet zijn omdat het totaal andere archs zijn, maar het draait wel.
Een architectuurswitch is Apple al minstens 2 keer prima gelukt, dus waarom zou Microsoft (toch de grootste OS leverancier) het niet kunnen?

Ik heb kort les gehad in x86 Assembly, maar damn, wat een overhead.

[SCRAP]

Natuurlijk kan Microsoft dat wel, dat hebben ze immers met Windows NT 5.0 (win2000) laten zien. Zoals ik al in m'n vorige post aangaf werd NT aanvankelijk voor de MIPS, Alpha en i860 ontwikkeld. Pas later kwam er een x86 versie, die met de komst van NT 5.0 zelfs nagenoeg volledig compatibel met de op MSDos gebaseerde Windows versies werd gemaakt. Daarnaast is er ook een Windows versie voor de Intel Itanium (IA64), terwijl dit een compleet nieuwe 64bit architectuur is, bestaat er toch de mogelijkheid om x86 code te draaien. Het draaien van x86 programma's geschiedt op een zelfde manier als het draaien van legacy programma's onder MacOs X, namelijk middels emulatie. Microsoft kan dit dus wel en doet het zelfs al langer dan Apple. Mocht in het meest onwaarschijnlijke geval toch de x86 instructieset vaarwel gezegd worden, dan kan en zal Microsoft neem ik aan een Windows versie ontwikkelen die wel degelijk op een bepaalde manier terugwaarts compatibel is met oude Windows versies. Helaas heb je dan te maken met snelheidsverlies ivm emulatie, maar misschien valt dat mettertijd te compenseren met de toenemende rekenkracht van nieuwere CPU's.

[kozue]

Ze kunnen windows niet zomaar naar een andere architectuur porten. MS heeft namelijk een probleem wat apple niet heeft: ze zijn voor de meeste hardware support afhankelijk van de drivers van de maker. Standaard heeft windows bij geen support voor hardware, op wat basis dingen na (installeer maar eens een machine opnieuw, het is iedere keer weer de soundcard, wifi, printer, usb modem, webcam en vooral de nog exotischere hardware die het niet doet). Apple levert een totaal oplossing, software en hardware op elkaar afgestemd, en zijn dus niet afhankelijk van 3rd parties.
Als MS windows naar een andere architectuur port, verliezen ze bijna al hun hardware en software support, oftewel, dan blijft er geen reden meer over om nog windows te draaien. Persoonlijk denk ik dat windows de enige reden is dat x86 nog niet gedumpt is. Linux maakt het niks uit waar het op draait (op een paar binary-only dingen na, zoals flash player), en Apple levert gewoon een OS mee op hun eigen gekozen hardware. Natuurlijk had je wat software problemen na de switch, maar apps zijn meestal wel op rosetta te draaien, in tegenstelling tot drivers.

[roeleboel]

Als er van windows gewoon al een nieuwe versie uitkomt (nu met vista is dat vrij duidelijk, maar dat was gelijkaardig met de introductie van xp, 2000, ...) verliezen ze al de helft van ondersteunde apparatuur omwille van drivers die anders moeten.

En of je als fabrikant voor een nieuwe windows onder x86 of onder god-weet-wat een nieuwe driver moet schrijven maakt niet zoveel uit: voor vista moest je toch zowat opnieuw beginnen wegens ander drivermodel, en dan maakt een andere architectuur echt niet zoveel uit: nieuwe/andere compiler onder de ontwikkeltools & beginnen de documentatie voor het nieuwe drivermodel door te nemen.

De reden dat windows gebruikt blijft worden is dat de mens een gewoontebeest is en schrik heeft voor verandering (als het dan toch moet veranderen: liefst zo weinig mogelijk oftewel: terug windows alsjeblieft), samen met het feit dat support voor windows relatief makkelijk te krijgen is (zowel voor bedrijven als de buurjongen die paraat staat helpen hierin mee), en dat heeft niks met x86 te maken.

[Freeaqingme]

Wat voor voordeel zou de consument ervaren bij een andere/nieuwe instructieset tov de x86?

[iceheart]

nadeel: oude zooi doet het niet/minder snel.

voordeel: meer potentieel voor sneller/goedkoper/zuiniger maken van je CPUs...

[J.J.J. Bokma]

je nadeel *hoeft* helemaal niet. Acorn deed die stap in de jaren 80. De Archimedes (met een snelle processor) kwam met een BBC emulator.

[mae-t.net]

Met de oude zooi werd dan ook de iAPX86 architectuur bedoeld. Dat de Archimedes met zijn ARM processor zijn tijd ver vooruit was, mag hopelijk algemeen bekend zijn.

[Reactie gewijzigd door mae-t.net op 23 juli 2024 05:39]

[Olaf van der Spek]

Dit hindert de ontwikkeling van onze pc's en bijbehorende chips enorm.

Dat is enorm overdreven.
De kosten van x86 compatibiliteit zijn helemaal niet zo hoog.

En andere architecturen, zoals van IBM en Sun, winnen het ook niet van x86.

[kozue]

Die hoeven het ook niet te winnen. IBM en Sun maken namelijk geen consumenten machines (meer).

[Anoniem: 142442]

Eigenlijk verwachtte ik - al langere tijd - dat Intel, al dan niet in samenwerking met MS, met een nieuwe, moderne en (veel) snellere processorlijn zal komen. Een nieuwe architectuur, waar inderdaad nieuwe programma's voor ontwikkeld zullen moeten worden.

Dat dit in het begin een nadeel is weet ik, maar dat kun je denk ik wel opvangen met een goede emulator of een virtuele pc waarop je een nu moderne pc kunt installeren voor zolang als het noodig is.

Maar dat zal wel iets te simpel gedacht zijn van mij...

[burne]

Wat ik mis, hoewel 'ie wel in de tijdslijn staat, is de 4004. Busicom, een Japans bedrijf wat calculators maakte (bepaald geen zakjapanners, overigens) benaderde Intel met de vraag of Intel de schema's die ze zelf ontworpen hadden kon omzetten in 12 chips en deze produceren. Intel kwam met een tegenvoorstel, een set van 4 chips, waarvan 1 programmeerbaar. De eerste drie (4001, een ROM, 4002, RAM en 4003 schuifregister) zijn roemloos ten onder gegaan, maar de 4004, een programmeerbare ALU, was toch wel een beetje de grootvader van de 8008, en daarmee de rest van de intel-familie.

[smrman]

Ik zie em wel, of heeft iemand em later in de grafiek gemodereerd ?

[Anoniem: 233768]

Hij mist een deel erover in het verhaal denk ik Maar leuke samenvatting van de geschiedenis van x86.

[XyritZz]

Wat ik mis is een stukje over de Pentium Pro, dit is toch de doodsteek geweest voor het RISC ontwerp, aangezien de Pentium Pro alle voordelen van RISC combineerde met de x86 instructieset.

[TommyboyNL]

Wat ook mooi is, is dat het complete ontwerp van de 4004 (schema, wafer masks, en dergelijke) gratis te downlaoden is van de Intel website: http://www.intel.com/museum/archives/4004ip.htm

[Reactie gewijzigd door TommyboyNL op 23 juli 2024 05:39]

[narcan]

Niet echt iets om trots op te zijn, deze instructie-set en vooral de bijbehorende hardware, was al achterhaald toen deze uitkwam. Heb gelukkig heel lang met de mc680x0 architectuur/instructie-set mogen werken, die in alle opzichten superieur was/is. Maar ja, als je niet beter weet...

[M.M]

Hartgrondig met je eens.. x86 is een draak van een instructieset.

[Anoniem: 261542]

intel is in feite inmiddels ook een RISC processor; de uops die intern uitgevoerd worden zijn RISC-achtige instructies die multi-scalaire pipelines e.d. mogelijk maken.

de overhead van het vertalen van x86 CISC naar uops is welliswaar aanwezig maar door de telkens verfijndere halfgeleider processtechnologie telkens minder relevant.

verder worden veel van de oorspronkelijke x86 instructies door compilers niet meer afgescheiden. zaken als FP-87 instructies worden nauwelijke meer gegenereerd door moderne compilers. ipv daavan worden SSE instructies gebruikt. volgens mij is het zelfs zo dat liefst moderne x86 instructies worden gegenereerd die zo makkelijk mogelijk mappen op de uops en zo de overhead van de CISC-RISC omzetting verzachten.

[J.J.J. Bokma]

Vzviw werken de meeste CISCs met microcode, en zijn dan volgens jou RISC. Iets als de Z80 zou dan ook een RISC zijn...

[g4wx3]

Ale .NET goed geport kan worden zijn we er misschien vlugger van af dan we zouden denken. Mede Universal Apps is OSX ook platform onafhankelijk.
Echter intels kennis over de x86 is zo geavanceerd dat ze probleemloos andere platformen aankunnen. Op specifieke vlakken is een Power, een niagara, een CELL, of een regulaire GPU sneller. Intel is all arround

[dtech]

Bedoel je Universal Binaries? die zijn absoluut niet platformonafhankelijk, het is gewoon x86 en PPC bij elkaar gepropt.
Het is wel waar dat in een verre toekomst waarin alles in .NET en java wordt geprogrammeerd je in theorie gemakkelijk over zou kunnen stappen op een andere instructieset. Je zou theoretisch zelfs chips kunnen maken die de JVM bytecode of .NET CIL direct uitvoeren.

[Anoniem: 124586]

En naar mijn insziens wordt dit de toekomst.

Chips die native .NET of Java (maar die bestaan al) draaien.

[A Lurker]

Als er .NET processors komen, dan is het monopolie van Microsoft compleet: software -en- hardware.

Voordeel is wel dat men van de x86 architectuur af kan stappen en dat Intel waarschijnlijk meer concurrentie zal kunnen krijgen.

Hoe wordt trouwens de y waarde in de grafiek bepaald voor een processor?

[Reactie gewijzigd door A Lurker op 23 juli 2024 05:39]

[poktor]

Is al compleet: Microsoft en Intel werken nauw samen en stemmen hun producten op elkaar af.

[Terracotta]

Intel werkt ook zeer goed met andere partners samen: linux drivers, specs geven... Alles wat intel aan MS geeft komt ook bij Linux terecht, dus zo compleet zijn ze nog niet, en laat ons hopen dat het nooit gebeurd.

[Anoniem: 116571]

.NET -> Micro Framework

Managed code in je horloge, nu nog toekomst muziek, maar het komt eraan

[Sijmen]

Chips die native .NET of Java (maar die bestaan al) draaien.

Maar dat is dan alsnog toch weer gewoon een architectuur erbij? x86, PPC, .NET, Java.

[drZymo]

De enige reden dat we de Intel 8086 herdenken en de anderen niet is omdat software geschreven voor de 8086 dertig jaar later nog steeds kan draaien op de nieuwste servers, desktops en notebooks.

Ik betwijfel of dit nog steeds geldt. De 8086 is 16-bits met een eenvoudige pipeline. De huidige processoren zijn 32-bits en hebben een complexe en lange pipeline. Ik denk dus niet dat alle code zomaar nog op de huidige processoren te draaien is. Dat alles werke vanaf de 80386 kan ik me wel voorstellen, want vanaf toen was het allemaal 32-bits, was er virtual memory ondersteuning (protected mode) en de instructie set is niet veel meer veranderd.

[Reactie gewijzigd door drZymo op 23 juli 2024 05:39]

[Xiphalon]

De code in je bootsector is toch echt nog steeds 16-bit code, welke prima uitvoerbaar is op een 8086.

[jvdmeer]

Ik denk dat het allemaal wel nog gaat werken, want de processor start niet standaard op in protected-mode. Daarmoet hij door het OS of in ieder geval de loader naar worden overgezet.

[Anoniem: 142442]

Als je die beschrijving leest, en verderop zag ik ook staan dat het verbruik (tdp?) van de 8086 ongeveer 5 Watt is, dan lijken de specs (behalve de snelheid!) veel op die van de Atom!
Cirkeltje rond?

[Reactie gewijzigd door Anoniem: 142442 op 23 juli 2024 05:39]

[Anoniem: 255280]

Niet alleen dat, AMD had ook al 186, 286 en 386 DX en SX CPU's.

http://www.cpu-collection...l1=8086/88&l2=AMD#D8086-2

http://www.cpu-collection...=80286&l2=AMD#R80286-8/C2

http://www.cpu-collection...386&l2=AMD#Am386DX/DXL-25

In de linkerkolom kan je zelf rond browsen.

[Reactie gewijzigd door Anoniem: 255280 op 23 juli 2024 05:39]

[Anoniem: 248486]

Een alerte collega van me heeft nog een foutje in het artikel gespot:

Er wordt 5 MHz genoemd, maar dit moet 4,77 MHz zijn

[arjankoole]

Ik zie maar 1 klein foutje in dit artikel: AMD had in de 486 tijd ook 486 CPU's, wel of niet geklooned laat ik even in het midden. Intel kwam toen volgens mij niet verder dan de DX2-66 MHz, AMD had nog een DX-100MHz en zelfs een stuiterende DX4-120MHz. (ik heb mijn DX4-100MHz overigens met veel succes, en geheel per ongelijk opgeblazen )

[Anoniem: 44174]

AMD had 386-DX40 terwijl intel niet verder ging dan 386-DX33 dat mis ik ook nog (heb hem hier nog staan mijn eerste pc een 386dx-40 van amd en ze hadden later ook nog sx uitvoeringen, weet ff niet meer wat daar mee was. Ik geloof dat dat dx uitvoeringen waren die minder goed waren of zoiets.
Iemand anders kan dat vast wel aanvullen.

[Reactie gewijzigd door Anoniem: 44174 op 23 juli 2024 05:39]

[kjoost]

Als ik me goed herinner waren de dx-en juist beter: die hadden namelijk een coprocessor voor floating point berekeningen, terwijl bij de sx-modellen die coprocessor ontbrak.

[wildhagen]

Bij de 386 zat er zowel in de SX als in de DX geen coprocessor, die werd pas in de 486 standaard (in 486SX was hij wel uitgeschakeld). In de 386 moest je, als je een FPU (coprocessor) wilde, een 387-processor bijprikken (in de 286 de 287, in de 8086, de 8087 etc).

De SX was de low-budgetversie van de DX. Het verschil was met name dat de SX extern slechts 16-bits was (intern wel 32-bits), terwijl de DX 32-bits was in- en extern. Daardoor kon de 386SX minder geheugen aansturen dan de DX.. Als ik me goed herinner had de SX ook een andere socket dan de DX (100-pins vs 132-pins).

[familyman]

idd

zo heb ik de dx ook verkocht aan mijn moeder. als ik deze neem en later een copro dan is het gelijk aan een 486. Dus eigenlijk een goed upgrade pad.

Het begin van de upgrade mythe. Het is natuurlijk nooit gebeurd. *zucht* memory lane...

[Shark.Bait]

goed upgrade pad...nee. De 486 DX had nl een zgn "local bus" die de 486 bij gelijke kloksnelheid twee keer zo snel maakte als zijn 386 broetje.
Dat heb ik bij geen enkel andere intel CPU meegemaakt, dat hij bij dezelfde kloksnelheid 2 keer zo snel zijn werk deed.

[InfinityG35]

Pentium 4 vs Core 2? Ik denk dat dat zelfs meer dan 2x zo snel is.

[TD-er]

AMD had 386-DX40 terwijl intel niet verder ging dan 386-DX33

Bij de 486 had je dat ook , maar de Intels waren -ondanks de lagere klokfrequentie- toch wel een stuk sneller in de praktijk.
Volgens mij kwam dat mede doordat de 33 MHz klok beter aansloot op de randapparatuur.

[Thandor]

Bij de Am386 DX/40 is dit niet het geval. Deze was juist een pak sneller t.o.v. de 386 DX/33 omdat de bus ook op 40MHz liep. Dat was eigenlijk ook de kracht van die chip .

Bij de 486 werd de DX/40 minder succesvol omdat onder andere een 40MHz bus voor meer problemen zorgde (dit gold ook voor de DX/50). De Am386 DX/40 was immers een laatkomer en de moederborden waren destijds al volwassen. Ten tijde van de Am486 DX/40 was de Intel 486 DX2/66 ook reeds op de markt en dat zorgde natuurlijk voor concurrentie.

[wildhagen]

Intel kwam toen volgens mij niet verder dan de DX2-66 MHz

Dat is niet juist. Intel had ook een 486DX4 op zowel 75 Mhz als op 100Mhz

Daarnaast had AMD dan wel de 486DX5, die op 133 Mhz liep. Dat was afaik de snelste 486 die er te krijgen was.

[Reactie gewijzigd door wildhagen op 23 juli 2024 05:39]

[Anoniem: 255280]

Die noemde officieel ook geen DX5 maar X5.

http://www.cpu-collection...&l1=486&l2=AMD#Am5x86-P75

[fevenhuis]

Tegen die tijd zat iedereen al aan de pentium.

[Anoniem: 153797]

"Gesher" heet nu "Sandy Bridge".

[stewie]

ff wachten tot de sandy bridge een oasis is
en AVX lijkt verdomt veel op de PPC's G5's AltiVec.
http://en.wikipedia.org/wiki/Advanced_Vector_Extensions

[Reactie gewijzigd door stewie op 23 juli 2024 05:39]