AMD staakt ondersteuning 3DNow-instructieset

De Amerikaanse chipontwerper AMD heeft aangekondigd dat de 3DNow-instructieset niet langer in al zijn toekomstige processors wordt ondersteund. Het bedrijf wil de inmiddels achterhaalde standaard geleidelijk uitfaseren.

AMD waarschuwt software-ontwikkelaars dat de 3DNow-instructieset in 'bepaalde' toekomstige processors niet meer wordt ingebakken. De instructieset, die sinds 1998 in AMD-processors aanwezig is, zorgt voor ondersteuning van single instruction multiple data- oftewel simd-instructies. Met de diverse sse-instructies is de 3DNow-standaard volgens AMD echter overbodig geworden.

Het bedrijf laat bij monde van technicus Randy VanderHeyden en 'developer relations engineer' Sharon Troia aan ontwikkelaars weten dat zij eventuele verwijzingen naar de 3DNow-instructies het best kunnen schrappen. De enige twee instructies uit 3DNow die nog wel ondersteund worden, zijn PREFETCH en PREFETCHW. Deze twee worden in een aparte nieuwe instructieset ondergebracht, die 3DNowPrefetch gaat heten.

Het wordt developers aangeraden om in hun code met behulp van het cpu-id te controleren welke 3DNow- en 3DNowPrefetch-instructies kunnen worden uitgevoerd. Daardoor kan code sneller worden uitgevoerd dan wanneer er op foutmeldingen van de cpu wordt gewacht, zo stelt AMD. Bovendien kunnen op die manier problemen met de migratie van virtuele machines voorkomen worden.

Reacties (55)

[djexplo]

Ooit was 3Dnow! suprieur aan SSE van Intel.
SSE had alleen wat instructies bruikbaar voor JPEG en MPEG en kon maar 1 optelling/vermenigvuldiging per instructie aan, en na een aantal instructies moest weer een clear instructie komen. Terwijl 3Dnow, 2 optellingen/vermenigvuldigingen per instructie ondersteunde en meer verschillende handige instructies aanbood.

Maar het is goed dat 3Dnow! er uitgaat, het ondersteund alleen floating point en geen doubles. Ook zijn efficientere instructies al beschikbaar in SSE2 en SSE3. Daarnaast is de enige compiler die echt automatisch optimaliseert naar 3Dnow instructies "Metrowerks CodeWarrior", die veel minder word gebruikt dan de Intel en Microsoft compilers.

[.oisyn]

Ik vind het maar een vaag verhaal, en ik kan me niet aan de indruk onttrekken dat je een aantal dingen door elkaar haalt (SSE en MMX, en de algemene instructieset en een specifieke implementatie ervan).

Als instructieset is SSE gewoon superieur aan 3DNow! (wat feitelijk 2DNow! had moeten heten, maar dat klinkt nou eenmaal niet zo hip). 3DNow! gebruikte namelijk de 64 bits MMX registers, waardoor je maar 2 floats per register op kunt slaan, die bovendien overlappen met de FPU registers waardoor het niet mogelijk was om FPU en MMX/3DNow! code door elkaar te gebruiken. SSE had daarentegen 8 dedicated 128 bits registers, waardoor er 4 floats in een register pasten en je bovendien FPU of MMX code kon mixen met SSE code. En dus kon je ook 4 bewerkingen per instructie doen (waarom denk je dat het Streaming SIMD Extensions heette?)

Het is weliswaar waar dat de eerste implementaties (Pentuim III) de FPU execution units gebruikte voor SSE code, waardoor FPU en SSE code niet kon pairen (de P3 kon dus niet tegelijk een FPU en een SSE instructie afhandelen), maar als architectuur was SSE een stuk bruikbaarder dan 3DNow!

[Reactie gewijzigd door .oisyn op 14 augustus 2024 02:19]

[mrlammers]

SSE is een uitbreiding op de IA-32 instructieset die SIMD functionaliteit geeft aan de floating point operaties. Deze uitbreiding was een logisch vervolg op MMX instructies die alleen integer data konden verwerken. 3DNow! is eigenlijk een MMX extensie.
Anno 2010 zijn deze instructies door de brute grafische processoren redelijk overbodig geworden.

[.oisyn]

Euhm, ja. Dat wat je zegt voor 3DNow! gaat ook op voor SSE (een uitbreiding op de IA-32 instructieset), en dat voor SSE gaat ook op voor 3DNow! (een logisch vervolg op de integer MMX instructies).

Anno 2010 zijn deze instructies door de brute grafische processoren redelijk overbodig geworden

Sorry maar dat is echt complete nonsens . In performance kritieke applicaties die veel met floating point berekeningen doen (games, simulaties) wordt SSE volop gebruikt. De GPU heeft dan wel veel meer floating point kracht, maar die komt vooral tot z'n recht als je hetzelfde algoritme heel veel keer in parallel wilt kunnen uitvoeren op grote datasets. Hij is veel slechter in het accessen van main memory en de roundtrip tijd (CPU -> GPU -> CPU) is ook nog eens behoorlijk lang, zeker als de GPU ook nog eens andere dingen moet doen (zoals daadwerkelijk graphics renderen).

Leuk voorbeeld: Frostbite 2, de grafische engine van Dice die gebruikt wordt voor Battlefield BC2, heeft een software zbuffer rasterizer voor het doen van occlusion queries. De GPU kan dat ook wel, een stuk sneller zelfs, maar je wil instant resultaat, terwijl de GPU druk bezig is de content van 1 of 2 frames geleden te renderen. Daar kun je gewoon niet op gaan zitten wachten.

[Reactie gewijzigd door .oisyn op 14 augustus 2024 02:19]

[mrlammers]

Ik verwees ook naar 3DNow! en niet naar SSE.

[.oisyn]

Wat net zo goed nergens op slaat, om de argumenten die ik daarnet gaf. Als 3DNow! achterhaald is dan is dat door SSE, niet door de GPU

[Anoniem: 2461]

Net wat .oisyn zegt, deze instructiesets zijn zeker nog bij de tijd: onlangs werd de ffvp8 codec nog ruim 50% versneld in vergelijking met de reguliere C code door slim gebruik te maken van MMX/SSE instructies.
Dus, eh, games, simulaties, videocoding.... best belangrijk, die SIMD instructies.

[MSalters]

3DNow! gebruikte [...] de 64 bits MMX registers, waardoor je maar 2 floats per register op kunt slaan, die bovendien overlappen met de FPU registers waardoor het niet mogelijk was om FPU en MMX/3DNow! code door elkaar te gebruiken.

Volgens mij haal je twee zaken door elkaar. Op Intel's Pentium implementatie van MMX overlapten de FP en MMX registers. Dat gold niet voor AMD's implementatie van MMX / 3DNow. Daarom kun je wel 3DNow code en FPU code door elkaar gebruiken, dat werkte sowieso niet op Intel chips.

[.oisyn]

Daarom kun je wel 3DNow code en FPU code door elkaar gebruiken

Vziw is dat nooit waar geweest. 3DNow! had zelfs een speciale instructie, femms, die sneller was dan emms, om de MMX/FPU state te resetten.

[ari3]

De Intel en Microsoft compilers zijn alleen veelgebruikt onder Windows. Wij gebruiken GCC (op Linux en Windows) en die optimaliseert ook prima voor 3DNow. Hoewel je in de meer recente AMD CPU's kun je net goed SSE instructies kunt gebruiken om hetzelfde te bereiken.

[Anoniem: 77640]

Ooit was 3Dnow! suprieur aan SSE van Intel.

Niks van waar.

SSE had alleen wat instructies bruikbaar voor JPEG en MPEG en kon maar 1 optelling/vermenigvuldiging per instructie aan...

Nonsense. SSE kon meteen 4 optellingen/vermenigvuldigingen per instructie. 3DNow! slechts 2.

...en na een aantal instructies moest weer een clear instructie komen.

Ook bullshit. Het is net 3DNow! dat een emms of femms instructie nodig heeft, aangezien het de MMX registers hergebruikt, die op hun beurt een alias zijn van de x87 registers. SSE heeft afzonderlijke 128-bit registers en is daarmee veruit superieur, zonder een emms-instructie te hoeven.

[Puppetmaster]

3Dnow! was ook eerder dan SSE, meer richting het MMX tijdperk.

[mrlammers]

MMX - 1996
Een hele slimme uitvinding van Intel waarbij kloktikken een stuk efficienter gebruikt werden: wij danken Intel dan ook voor de packed versies van de byte, word, doubleword, de quadword en een handje vol slimme instructies.

3DNow! - 1998

SSE (KNI) -1999
Deze uitbreiding op SIMD instructies met 32-bit floating point ondersteuning en een extra setje 128-bit vector registers maakte het mogelijk om SIMD en FPU operations tegelijk uit te voeren.

SSE2 - 2001
De integer registers zijn vergroot van 64 naar 128 bits en er kunne double precision floating point data in de floating point registers geladen worden. Dit heeft als voordeel dat er minder wisselingen in de MMX registers plaatsvinden. Helaas zag je niet veel performanceverbetering, maar toch: Yay, voor SSE2!

SSE3 (PNI) - 2004
13 nieuwe instructies voor SSE én veel belangrijker: we kunnen nu zowel horizontaal als vertikaal door de MMX/SSE registers heenbladeren! Een van de nieuwe instructies zorgt ervoor dat we straffeloos floating points naar integers kunnen converteren.

SSSE3 (TNI) - ?
16 nieuwe instructies, ondanks dat Intel claimde dat het er 32 waren. Een stiekume instructieset voor de Core2Duo's en de Xeons?

SSE4 - 2007
Okee, hier raakte intel een beetje de weg kwijt. Waarom was SSSE3 niet SSE4? Waarom kwamen er na de introductie van SSE4 in 2006 nog een hele bak met subsets: 4.1, 4.2, 4a (AMD)?
Welke processoren ondersteunen nu wat? WElke instructie horen nu officieel bij SSE4?
Niemand die het weet.

SSE5 - 2007
Voorstel van AMD om SSE te integreren met de 128-bits SSE core in de AMD64 architectuur.
AMD heeft haar eigen voorstel afgeschoten en heeft 'SSE5' vervangen door drie kleinere instructie sets, genaamd: XOP, FMA4 en CVT16. De functionaliteit is overeind gebleven, maar zorgen nu voor een betere compatibiliteit met Intel's AVX instructie set. Zie: http://en.wikipedia.org/wiki/Advanced_Vector_Extensions

En waarom heet AVX niet SSE6 ?

[Reactie gewijzigd door mrlammers op 14 augustus 2024 02:19]

[.oisyn]

[SSE2] De integer registers zijn vergroot van 64 naar 128 bits

Wat is is veranderd is dat de MMX registers sinds SSE2 ook gebruikt kunnen worden in de SSE2 instructies, en dat de integer instructies voor MMX ook SSE2 registers kunnen gebruiken. Er zijn verder geen registers verbreedt oid, de MMX registers zijn nog steeds 64 bits en de SSE registers nog altijd 128 bits..

[mrlammers]

MMX had twee tekortkomingen: met het hergebruiken van floating point registers kon de processor niet tegelijk floating point en SIMD data tegelijk verwerken en MMX kende alleen maar integers.
SSE heeft dat opgelost.

MMX registers zijn nog steeds 64 bits en de SSE registers nog altijd 128 bits..

Klopt. De MMX registers werden ind erdaad niet verbreed. My bad. Wat ben jij goed!
Maar, als ik me niet vergis dan breidde SSE2 de MMX instructies uit zodat ook XMM registers aangesproken konden worden en die zijn wel 128-bit.
Hierdoor konden ook integere SIMD en scalaire floating point operations tegelijk gedaan worden zonder mode switching tussen MMX en x87 floating point operations. Ik zeg: dikke winst.

AMD's implementatie van SSE2 op het AMD64 platform heeft zelfs 8 extra registers meegekregen. Deze extra registers zijn alleen beschikbaar als je in 64-bit modus draait. Intel doet dat inmiddels ook geloof ik.

[Reactie gewijzigd door mrlammers op 14 augustus 2024 02:19]

[Anoniem: 190909]

Dus die 3DNow! instructies worden nu Unused Opcodes, en geven enkel een NOP (90h) effect in de CPU (NOP= No OPeration)?

[johnbetonschaar]

Als de CPU een illegal instruction tegenkomt wordt er een CPU exception geraised, welke normaliter door het OS wordt afgevangen om een nette 'Application Error' oid. te laten zien en het proces af te sluiten. De manier waarop dit wordt gesignaleerd is dezelfde als bij bijvoorbeeld een page/segmentation fault, een arithmetic exception, stack fault, dat soort dingen.

CPU exceptions zijn softwarematig af te vangen zodat je de ontbrekende instructie zou kunnen emuleren in software zonder het proces te crashen, maar omdat de exceptie via een hardware interrupt werkt is dat heel erg traag. Vroeger werd op deze manier nog wel eens een FPU ge-emuleerd op CPUs' die er geen ingebouwd hadden (386's en de eerste 486's)

[Anoniem: 190909]

Illegal opcodes triggeren interrupt 6 vanaf de 80186 lees ik. Dit is echter een software interrupt, aangezien er geen interrupt controller voor randapparatuur gebruikt wordt.

[serkoon]

Normaal gesproken zijn niet-gebruikte opcodes ongeldig en crasht je programmatuur er op vanwege een fault. Dat lijkt me dus waarschijnlijker.

[Anoniem: 190909]

Illegal Opcodes zijn niet meer van deze tijd. Vroeger zaten ze als easter eggs in je homecomputer (de ZX Spectrum en de Commodore 64 hadden er enkele geloof ik). Zowel Intel als AMD processoren hebben (vanaf de 8086 al dacht ik) tegenwoordig ingebakken dat onbekende operatiecodes gewoon niets doen in het systeem, zodat de computer niet crasht. Het is eventueel de taak van bovenliggende software-interpreters (bijvoorbeeld het operating system) om de 'illegal' instructies af te vangen.

[serkoon]

Ze doen dus wel degelijk iets: namelijk een fault triggeren, zodat je OS een SEH kan uitvoeren (Windows) of signal (*nix) kan sturen.

[Anoniem: 190909]

http://en.wikipedia.org/wiki/Illegal_opcode

Als de processor ze zelf niet afvangt, kan die rare dingen gaan doen, waar de CPU-ontwerpers de processor oorspronkelijk niet voor ontworpen hebben. Tegenwoordig wordt er gewoon een error-flag of error output enabled, of de CPU doet 1 of meerdere NOP's, of beide.
Ook worden CPU's tegenwoordig eerst grondig getest met alle mogelijke opcode-inputs, inclusief operanden. Dat was in de tijd van bijv. de MOS 6502 wel anders.

[robvanwijk]

Ook worden CPU's tegenwoordig eerst grondig getest met alle mogelijke opcode-inputs, inclusief operanden.

Dat is al niet waar voor "alle mogelijke opcode-inputs", laat staan voor "inclusief operanden". Opcodes kunnen héél lang zijn (uit mijn hoofd: 12 bytes). Dat betekent niet dat er 2^(8*12) opcodes zijn; alle 12-byte opcodes die "beginnen" met een byte die op zichzelf een geldige (1-byte) opcode is kunnen simpelweg niet bestaan. In totaal heb je echter een enorme hoeveelheid mogelijke opcodes. Die allemaal testen is niet te doen. Zeker niet omdat je er niet eentje wil uitproberen, maar ook wil weten of er niet ergens iets in een rare toestand wordt achtergelaten zodat een volgende instructie opeens fout gaat.
Je kunt niet eens de ADD testen voor alle mogelijke inputs. In een 32-bits machine heb je namelijk twee inputs van elk 32 bits (en nog een carry-bit), zodat je 2^65 > 10^19 combinaties moet testen. Zelfs op 10 GHz (10^10 instructies per seconde) kost dat 10^9 seconden; tientallen jaren. Maak er een 64 bits CPU van, met zeer veel instructies die getest moeten worden en euhm... Voorzichtig uitgedrukt: dat gaat niet werken.

[Anoniem: 366402]

Het feit dat aangeraden wordt om te checken op CPUID houdt waarschijnlijk in dat de instructies er helemaal uitgaan, dus de bijbehorende opcodes ook.
Logischerwijs zullen oudere programma's die gebruik maken van 3DNOW ook al een check hebben, aangezien je ook lange tijd CPU's had zonder 3DNOW.

[Anoniem: 190909]

Programma's die 3DNow! gebruiken hebben idd die check. Als 3DNow! niet aanwezig is in de processor wordt het 'regular' deel van het programma gebruikt. Vaak wordt zo'n programma (of game) hybride geschreven of gecompiled: voor elke combinatie aan instructiesets één.

[robvanwijk]

Ik heb nog nooit gehoord van een CPU waar alle unused opcodes beschouwd worden als NOPs (dat betekent natuurlijk niet dat ze niet bestaan).

Normaal gesproken, op moderne (microcoded) CPUs wordt er op de een of andere manier een error veroorzaakt, die meestal ook weer afgevangen kan worden (bijvoorbeeld zodat het effect van de instructie op een andere manier alsnog bereikt kan worden en het programma vervolgd kan worden).

Voor de volledigheid, in "oude" (hardwired) CPUs was er een andere oplossing:

quote: http://www.ticalc.org/pub/text/z80/z80opcod.txt

By the way, the reason these instructions exist even though they were not part of the original CPU design: the Z-80 was the most complex microprocessor ever to be completely hard-wired (no microcode). As a result -- as anyone who's ever taken a logic design course can tell you -- it's much easier to have "undefined states" do whatever-comes-easiest.

De Z80 heeft o.a. de 8-bit registers H en L, die samen gebruikt kunnen worden als het 16-bit register HL. Ook is er een 16-bit register IX. Officieel gezien kan IX niet als twee losse 8-bit registers gebruikt worden. Maar, de instructies die IX gebruiken zijn dezelfde als degene die HL gebruiken, maar dan met de byte 0xDD ervoor. Dus als je de volgende instructies kent:
23          INC HL
24          INC H
DD 23   INC IX
Dan is het niet heel verwonderlijk dat deze ook bestaat:
DD 24   INC HX
(Register HX bestaat officieel niet; het is de "bovenste" 8-bits van IX. De naam zal wel bedacht zijn door iemand die deze undocumented opcodes ontdekt heeft.)

Overigens, jouw aanname komt hier wel ongeveer terug:

quote: http://www.ticalc.org/pub/text/z80/z80opcod.txt

All other DD combinations not listed below: DD is ignored, all following bytes are treated as instructions

Dus bijvoorbeeld (al heb ik even niks bij de hand om het te controleren):
FF          RST 38H
DD FF   RST 38H
(Ik heb FF gebruikt als voorbeeld omdat 00 een onhandig voorbeeld is: dat is op de Z80 namelijk NOP.)

edit:
Hmm, de pre-tag werkt hier niet... Dan maar met non-breaking spaces...

[Reactie gewijzigd door robvanwijk op 14 augustus 2024 02:19]

[feelthepower]

Wat zou de reden van het schrappen zijn? Ruimte maken voor nieuwe instructies?

[Anoniem: 190909]

Scheelt geheugen in de Control Store idd (microprogramma).

[Anoniem: 112442]

Scheelt geheugen in de Control Store idd (microprogramma).

Ik denk dat het ook een stuk hardware scheelt. Dit betreft code tot het berekenen van vectors en floats. Als je dit alleen door microcode oplost gaat dit ten koste van performance.

Intel zou een keer een voorbeeld aan AMD moeten nemen. En prehistorische zaken zoals Real Mode en andere niet meer wenselijke/niet gebruikte modes uit de processor te slopen.
Wat automatisch ook zou betekenen dat de [url=-http://en.wikipedia.org/wiki/Master_boot_record#System_bootstrapping]huidige BIOS niet meer bruikbaar zal zijn[/url].

[albatross]

[...]

Intel zou een keer een voorbeeld aan AMD moeten nemen. En prehistorische zaken zoals Real Mode en andere niet meer wenselijke/niet gebruikte modes uit de processor te slopen.

Real Mode bestaat sinds de 386 al niet meer. Wat daar nog 'real mode' genoemd werd was feitelijk een uitgeklede variant van Protected Mode (ala V86 mode), waarbij de base-segmenten geladen werden met 'null-descriptors' (allemaal een basis-adress van 0), interrupts op de 'real mode' manier werden afgehandeld, en alle protectie mechanismes effectief 'uitgezet' waren (anders dan V86 mode dus, wat wel protectie bood, plus een gevirtualiseerde address-space). Zo had je iets dat zich gedroeg als 'real mode'; maar echte 'native' Real Mode had alleen de 286 nog.

[Reactie gewijzigd door albatross op 14 augustus 2024 02:19]

[depeje]

Als je bios niet meer werkt na de sloping, zijn die instructiesets wel wenselijk. Eerst het bios volledig uitfaseren, en dan de instructiesets.

[Anoniem: 190909]

Ik denk dat het ook een stuk hardware scheelt. Dit betreft code tot het berekenen van vectors en floats. Als je dit alleen door microcode oplost gaat dit ten koste van performance.

Een bepaald co-processor circuit kan inderdaad ook verwijderd worden. Scheelt nog meer transistors.

[Anoniem: 366402]

Af en toe moet je eens opschonen, anders word het een puinhoop. Iets dat je niet meer gebruikt moet je weggooien. Een principe dat een hoop mensen thuis ook wel eens zouden kunnen toepassen.

[latka]

D'r zit nog wel meer in de x86 architectuur wat weg zou kunnen (alle 16-bits spullen bijv.) aangezien niemand meer Windows 9x gebruikt. Toch ken ik geen andere voorbeeld van instructies die verdwenen zijn in de x86 wereld.

[ari3]

Mwah, 16-bit realtime mode is nog steeds nuttig. Ik vind het wel prettig dat je nog steeds DOS kunt booten.

[Neko Koneko]

Waarvoor boot jij nog DOS dan? Memtest? Gewoon Linux Live CD-tje starten

[Madshark]

En wat dacht je dan:
-Flashen van hardware zoals SSD's, Netwerkkaarten, Harddisks, moederbord etc.
-Drive imaging
-Drive recovery
etc

[DLGandalf]

allemaal dingen die je ook in protected mode/32bit of rechtstreek via BIOS pre-post. Toegegeven alleen met relatief nieuwe hardware gaat dit op, maarja alle oude hardware die dos nodig hebben om te flashen is toch al op een andere manier niet meer compatible, meestal socket kwestie. Dus wat ik bedoel is, als je echt zoiets gaat flashen, dan heb je toch een oude pc nodig waar alleen nog cpu's in passen met jouw geliefde 16bit real mode

[Reactie gewijzigd door DLGandalf op 14 augustus 2024 02:19]

[Goderic]

Ik moest mijn Intel SSD anders nog flashen met freeDOS.

[Cassius]

AMD K6-2 500MHz met 3DNow! ... wat een goede herinnering . Ik had deze processor toen samen met een Savage2000 kaartje wat ervoor zorgde dat ik Unreal Tournament kon draaien in S3 MeTaL mode op 1024x768 met 60fps - bijzonder mooi en flitsend toen der tijd. Raar dat je van zoiets 'materialistisch' als computers toch nostalgisch kan worden, zal wel komen door alle associaties die ik met die config heb.

* Cassius zwaait naar 3DNow!

Het waren mooie tijden meid .

[Palomar]

Die K6-2 500 heb ik ook gehad, maar was een behoorlijk traag ding.. Qua snelheid in spellen vergelijkbaar met een Pentium 2 300MHz oid. 3Dnow deed daar weinig aan Destijds sowieso nooit gemerkt dat 3Dnow geoptimaliseerde spellen merkbaar sneller draaiden....

[Reactie gewijzigd door Palomar op 14 augustus 2024 02:19]

[Cronax]

Dan ben je een van de weinigen die met een lach terugdenkt aan een AMD K6, die dingen waren notoir slecht...had er zelf ook eentje, gekregen...beter als niets en gegeven paard enzo, maar toch...

[johnbetonschaar]

De K6 en K6-2 waren absoluut niet notoir slecht, destijds was het zelfs zo'n beetje de beste CPU voor thuisgebruik die je kon krijgen. Klok voor klok waren ze sneller dan alle Pentiums, grotere L1 caches, en ze hadden dus al 3DNow! voordat er Pentiums met SSE bestonden. Enige nadeel van die chips was dat ze berucht waren erg heet te lopen en simpelweg kapot knalden als je fan er mee ophield.

Je moet die dingen wel vergelijken met de Pentiums van die tijd (de P5 generatie en de allereerste Pentium-II's). Dus niet met de latere Pentium-II's die stukken beter waren dan de eerste versies, toen die uitkwamen had AMD de K6-3, en daarmee zijn ze destijds op achterstand gekomen. De K7 kon ook geen potten breken, en pas bij de Athlon Thunderbirds was AMD weer competatief.

Ik denk dat jij juist een van de zeldzame mensen bent die die generatie CPU's nog heeft meegemaakt die de K6 chips als 'notoir slecht' bestempelt, het was juist een bijzonder goed ontwerp dat Intel aardig opgejaagd heeft zijn Pentium-II's beter te maken.

[Reactie gewijzigd door johnbetonschaar op 14 augustus 2024 02:19]

[MSalters]

Ik denk dat je je tijdslijn een beetje scheef hebt. De K6-2 is pas in mei 2008 geintroduceerd, terwijl het laatste model Pentium II (Deschutes 450 Mhz) in augustus 2008 geintroduceerd werd. Je mag ze dus zeker vergelijken. Ook mag je de K6-3 (Feb 1999) vergelijken met de Pentium III (ook Feb 1999) - en die P3 Katmai was weer net iets sneller.

Je hebt wel een punt als je zegt dat het een goede keus voor thuisgebruik was. Ze waren vooral veel goedkoper dan vergelijkbare Pentiums. Pas met de Athlon K7 kon AMD Intel in snelheid voorbij, en dat kwam mede doordat de P3 Coppermine op zich liet wachten en het RDRAM niet zo geweldig werkte.

[Aham brahmasmi]

Ik denk dat je je tijdslijn een beetje scheef hebt. De K6-2 is pas in mei 2008 geintroduceerd, terwijl het laatste model Pentium II (Deschutes 450 Mhz) in augustus 2008 geintroduceerd werd. Je mag ze dus zeker vergelijken. Ook mag je de K6-3 (Feb 1999) vergelijken met de Pentium III (ook Feb 1999) - en die P3 Katmai was weer net iets sneller.

K6-2 en PII geïntroduceerd in 2008?? Je zit er minstens 10 jaar naast en nog wordt je omhoog gemodereerd...

[Harry_Sack]

In mijn beleving was mijn k6-2 ook super veel sneller door 3Dnow!

Ik geloof dat je toen zo'n wine-achtig product had van Sun indertijd. Je kon toen je Ultra 10 upgraden met een insteekkaart, waar een k6 of een k6-2 op zat. In feite was het een moederbord die je binnen Solaris kon booten. Een leuk ding in een leuke tijd

[Xellence]

Dan moet ik maar 1 PC in stand houden voor Quake 2 met 3Dnow optimalisaties te kunnen blijven spelen Overigens nooit iets van gemerkt dat deze versie daadwerkelijk sneller was dan het origineel.

[Hydra]

Waarom zou je daarvoor in hemelsnaam een aparte PC willen bewaren? Quake 2 ondersteunde native OpenGL (dus een moderne machine blaast die oude met 3DNow uit het water), en je kunt ook nog een van de vele ports (de Quake 2 source is opensource) die de engine verder verbeterd hebben gebruiken. Heck, d'r is zelfs een HTML5 versie van.

[Fiander]

Mooi, nu ook MMX schrappen, en wat andere meuk bv protected mode ring 1 & 2
en versnelt overgaan naar EFI zodat de real mode icm het gehele 8 en 16 bit gedoe weg kan,
en we hebben weer wat transistortjes minder nodig.

[.oisyn]

bv protected mode ring 1 & 2

Waarom? Die ene bit (nu bestaat de privilege level namelijk uit 2 bits - 4 mogelijkheden) gaat echt niet veel uitmaken hoor.

[Anoniem: 190909]

En het is gedaan met de x86 backwards compatibilty

[SuperNull]

Ik neem aan dat VM makers dit makkelijk kunnen gaan afvangen waardoor je wel gewoon je oude crap kan draaien zolang je het op een hypervisor doet.
Dan is er niets aan de hand want 9x/early XP dingen draaien toch al niet (goed) meer zonder speciale maatregelen.

[ingmaronline]

Ik zou niet weten wat het is.. 1998.. Toen hadden we nog een zwart wit laptop thuis

[Emielio]

Heeft alleen niets met dat jaartal te maken, aangezien vanaf begin jaren 90 kleurenschermen mainstream was. Onze eerste pc, in 1992 gekocht had een 16 kleuren vga scherm.

[mdj84nl]

ik zal er geen minuut minder op slapen.