Channels
Powered by True

Main » Nieuws » Technologie & Wetenschap » Intel stopt vijftig nieuwe instructies in 45nm-chips

Intel stopt vijftig nieuwe instructies in 45nm-chips

Door Wouter Tinus, donderdag 28 september 2006 03:27
Bron: Intel, views: 24.162

Intel heeft aangekondigd dat zijn 45nm-processors voorzien zullen worden van ongeveer vijftig nieuwe instructies, die samen SSE4 zullen worden genoemd. De functies kunnen grofweg verdeeld worden in drie groepen: het eerste en overgrote deel is bedoeld om multimedia te versnellen, waaronder spellen, video en 2d/3d-rendering. Om dit soort toepassingen te helpen geeft de instructieset ontwikkelaars en compilers meer gereedschap om met vectoren te werken. Ondanks het feit dat er op dit moment al 259 instructies bestaan in SSE1 tot en met SSE3, hoefde men zich verrassend genoeg toch niet in vreemde bochten te wringen om nog nieuwe features te verzinnen: vrij voor de hand liggende operaties als het opzoeken van het laagste of hoogste getal, afronden, vergelijken en het uitrekenen van een Dot Product (standaardgereedschap voor alles wat zich met 3d bezighoudt) zitten er kennelijk nog niet in. Andere nieuwe instructies verbeteren de prestaties door de samenwerking tussen normale code en vectorcode te versoepelen, bijvoorbeeld door snelle conversie tussen verschillende datatypes.

Het tweede belangrijke deel van SSE4 zijn instructies die het doorzoeken en vergelijken van tekst versnellen. Intel verwacht dat deze erg nuttig zullen zijn voor zaken als virusscanners, compressie, databases en compilers. Ten derde zullen er nog een paar applicatiespecifieke functies worden toegevoegd: een hardwarematige implementatie van het CRC-algoritme (dat bijvoorbeeld gebruikt wordt om te controleren of bestanden intact zijn) en een zogeheten 'pop counter' die telt hoe vaak de binaire 1 voorkomt in een getal. Laatstgenoemde is nuttig voor patroonherkenning en schijnt naast de officiële doelstellingen als handschriftsoftware en gen-analyse ook populair te zijn bij crypto-analisten.

Overigens is de naamgeving 'SSE4' voor sommige mensen wellicht verwarrend, want eerder werd her en der aangenomen dat de nieuwe instructies in de Core 2-processor zo (zouden gaan) heten. De 32 nieuwe instructies in Woodcrest, Conroe en Merom schijnt men echter niet spannend genoeg te vinden om een nieuw versienummer te rechtvaardigen, en deze zijn nu dan ook officieel omgedoopt tot 'Supplemental SSE3'.

Intel SSE4

Volgende: Steve Wozniak schrijft het Apple-verhaal op 10:04
Vorige: Nieuwe exploits voor Powerpoint in het wild 23:59

Categorieën

Gerelateerde artikelen

Reacties

Flat modeFlat mode Sorteer aflopendSorteer aflopend Moderatie FAQModfaq
Niveaufilter: -1 Ongewenst: 48 reacties zichtbaar480 Neutraal: 47 reacties zichtbaar47+1 Meerwaarde: 22 reacties zichtbaar22+2 Verplicht leesvoer: 9 reacties zichtbaar9
«  1  2  »

Door -GSF-JohnDoe, donderdag 28 september 2006 03:30

Score: 2
Worden veel van dit soort instructies niet al door de video kaart gedaan? Het is wel fijn dat een cpu dit ook kan, maar je zou denken een video kaart kan het nog altijd sneller.

Door dwergkip, donderdag 28 september 2006 03:34

Score: 0
dan zou het ook geen bal uitmaken wat je voor procesor er in je kast zit als een videokaart het sneller kan

Door Wouter Tinus, donderdag 28 september 2006 03:40

Score: 2
Er is een beetje een strijd aan het ontstaan tussen videokaarten die meer algemene functies krijgen en processors die meer specifieke functies krijgen. Hoewel ze nooit alle taken van elkaar over kunnen nemen is er wel een grijs gebied dat Intel zoveel mogelijk aan zijn kant van het spectrum (de processor dus) wil houden. Intel is er namelijk geheel niet bij gebaat als de behoefte aan meer rekenkracht afneemt c.q. verschuift naar ander componenten die ze zelf niet maken ;).

Door dwergkip, donderdag 28 september 2006 03:51

Score: 1
zou het?

http://www.intel.com/support/graphics/sb/cs-023086.htm

Door Wouter Tinus, donderdag 28 september 2006 03:55

Score: 2
Ik weet dat ze marktleider zijn op het gebied van graphics als het gaat om aantallen, maar hun prestaties zijn bijna lachwekkend te noemen vergeleken bij die van ATi en nVidia (hoewel er tekenen zijn dat ze willen gaan inhalen). Een geïntegreerde videochip vormt in ieder geval geen enkele bedreiging voor een processor, terwijl dikke GeForce of Radeon dat wel is voor bepaalde toepassingen.

Door dwergkip, donderdag 28 september 2006 04:26

Score: 1
lachwekkend? daar zijn ze helemaal niet voor gemaakt, jij en ik spelen misschien graag een spelletje, zijn er genoeg die al dat 3d geweld helemaal niet nodig hebben

en intel is bezig met een cpu met 32 cores waarbij wat nu de gpu is onderdeel wordt van de 86x pipeline, is 4 keer vlugger dan wat een losse 'dikke' gpu daar tegenover kan stellen, waarom denk je dat amd ati heeft overgenomen?

Door Wouter Tinus, donderdag 28 september 2006 05:56

Score: 1
lachwekkend? daar zijn ze helemaal niet voor gemaakt, jij en ik spelen misschien graag een spelletje, zijn er genoeg die al dat 3d geweld helemaal niet nodig hebben
Thank you Captain Obvious :/. Het gaat in deze subdiscussie over dingen die een GPU eventueel sneller kan doen dan een CPU. Als het 3d-geweld van Intels videochips al waardeloos is, wat zegt jou dat dan over de geschiktheid van die dingen voor andere soorten werk?
en intel is bezig met een cpu met 32 cores waarbij wat nu de gpu is onderdeel wordt van de 86x pipeline, is 4 keer vlugger dan wat een losse 'dikke' gpu daar tegenover kan stellen
Dit bevestigt precies mijn originele punt dat er een strijd gaande is tussen processors en videokaarten.

Door DikkeDouwe, donderdag 28 september 2006 09:22

Score: 0
en intel is bezig met een cpu met 32 cores
De marketing afdeling werkt schijnbaar nog echt heel goed bij Intel. AMD doet vast ook onderzoek (is bezig) naar een processor met 1024 cores. Van onderzoek naar eind-produkt is nog een heel lange weg.
edit:
Ik trek mijn keudel terug :)
http://www.computerbase.d...tel_prototypen_80_kernen/
@Countess
Een FPU zou dus alleen een floating point berekening kunnen uitvoeren maar geen commando's. En er staat in het stuk nergens dat het slechts om FPUs gaat. Er staat zelfs duidelijk dat de cores een zeer vereenvoudige commandoset bevatten die schijnbaar alleen met Floating Point waarden kan rekenen. Laten we wel wezen de x86 architectuur zeker met de uitgebreidere commandosets (zoals SSE3, SSE4, etc...) maken de structuur log. Om 80 van dergelijke CPUs naast elkaar te produceren op 1 chip zal een heidenskarwei worden. Ik vind het de juiste weg die Intel ingaat (ik had eigenlijk gehoopt dat AMD deze weg op zou gaan). Vooral ook omdat de software steeds meer platform onafhankelijk geschreven wordt en ook OSen kunnen ondertussen vrij eenvoudig worden geport.

Door Countess, donderdag 28 september 2006 10:03

Score: 0
die 80 cores zijn enkel hele simplele floating point units.
leuk, 80 bij elkaar maar vrij beperkt toepasbaar en vormen samen geen echt cpu.
enige nut dat ik kan bedenken is een co-processor bijvoorbeeld.

Door hansg, donderdag 28 september 2006 11:42

Score: 0
Vanaf 32 cores wordt het allemaal anders: dan hebben we helemaal geen GPU meer nodig. 32 CPU's is namelijk voldoende om in realtime te kunnen raytracen.

Linkje, voor de geinteresseerden: http://www.openrt.de/

Door peke, vrijdag 29 september 2006 11:20

Score: 0
32 cores zijn dan misschien wel krachtig genoeg, de bandbreedte en latencies vd fsb of HT zijn lachwekkend ivm het huidige GDDR3/4.
Er zal dus altijd behoefte zijn aan gpu's.

Door abraxas, donderdag 28 september 2006 09:00

Score: 1
Het renderen van graphics in Maya of 3D Studio Max, wordt niet over de GPU gedaan. Dit soort software kan wel profiteren van dit soort instructies.

Door klaafstra99, donderdag 28 september 2006 09:19

Score: 2
Zolang de software er niet voor geschreven is, heb je er (helemaal!) niks aan.

Door Countess, donderdag 28 september 2006 09:30

Score: 1
niet persee geschreven. het moet iniedergeval ondersteund worden door de compiler waarmee het gecompileerd is.
veel dingen kan de compiler namelijk automatische toepassen.

maar bepaalde stukken herschrijven kan echter zeker geen kwaad voor een aantal dingen als je ze echt optimaal wilt benutten.

Door RobLemmens, donderdag 28 september 2006 10:19

Score: 0
En daar komt spul als .net goed tot zen recht. Je compileerd naar de intermediate language en voila, ten tijde dat de applicatie gestart word op de gebruiker zijn computer wordt deze gecompileerd naar machine code en kan er automatisch gebruik van de nieuwe instructies gemaakt worden. Zelfs als deze er niet eens waren toen de software geschreven werd.

Door mike_mike, donderdag 28 september 2006 10:58

Score: 0
En daar komt spul als .net goed tot zen recht.
In theorie ja. In de praktijk is het vaak wel degelijk nodig om in de broncode zelf efficienter om te gaan omdat je weet hoe het later in machinetaal en op de processor afgehandeld kan worden. Sommige processen kun je bundelen of juist splitsen om een sneller resultaat te krijgen. Compilers en .NET zijn geen programmeurs die jouw code wel even perfect herschrijven, het is een vertaling zodat het WERKT op de target machine.

Dat kan ook betekenen dat er soms juist grootste gemene delers gekozen worden die juist minder snellere code opleveren. Compatibiliteit is het hoofddoel, niet prestatie.

Beetje offtopic, maar het is toch ook niet zo dat .NET bij elke willkeurige software ervoor zorgt dat de applicatie opeens efficient multithreaded is? Dat is nog altijd de taak van de broncode zelf.

Door SKiLLa, donderdag 28 september 2006 11:38

Score: 0
Ik denk dat RobLemmens bedoelt dat nieuwe versies van VMs & JIT (zoals oa. Java & .Net gebruiken) bestaande code efficienter/sneller kunnen uitvoeren (op die hardware) zonder dat de broncode hoeft te worden aangepast ...

Multi-threading is niet relevant in deze context, het gaat erom dat een JIT compiler efficientere/snellere native-code kan genereren zonder een source-recompile (naar VM opcodes).

Trouwens, met "het is een vertaling zodat het WERKT op de target machine" doe je moderne JIT compilers wel tekort hoor; zo kan de .Net JIT b.v. SSE2 instructies genereren indien je machine dat ondersteunt ... De evaluatie van ondersteunde instructies vindt plaats @runtime en zal dus altijd optimaal gebruik maken van de aanwezige hardware.

Door Wouter Tinus, donderdag 28 september 2006 07:04

Score: 2
Wat is de code naam van deze processor "Trashcan" "recyclebin"?
Penryn.
[rant over legacy troep]
Backwards compatibiliteit is de drijfveer van de pc-industrie. Nieuwe x86-processors die oude software niet of traag draaien zouden simpelweg floppen. Bovendien is het echt niet zo dat men vandaag de dag nog veel tijd besteed om exotische instructies uit het DOS-tijdperk te implementeren. Lelijke dingen uit het verleden worden alleen nog maar functioneel gemaakt, de optimalisatie van het ontwerp (het echte moeilijke werk) gebeurt alleen voor moderne code. De echte gedrochten zitten zelfs alleen nog maar in software (micro-code) op de chip.
Volgens mij is dit niet in het belang van het vermogens gebruik en produktie kosten?
Dat valt nog maar te bezien. Deze instructies kunnen ervoor zorgen dat er meer werk in hetzelfde aantal kloktikken gedaan wordt (betere prestaties per watt) of dat dezelfde hoeveelheid werk eerder af is en de chip dus eerder terugkan naar slaapstand (zuiniger). Qua productiekosten zou het me verbazen als een 45nm Core2 duurder is dan een 65nm Core2.

Door worldcitizen, donderdag 28 september 2006 08:50

Score: 0
Backwards compatibiliteit is de drijfveer van de pc-industrie.

Ik denk dat Apple anders bewezen heeft. Ze gebruiken al de derde processor in hun Mac type. Eerst 68000 familie daarna PowerPC en nu x86.

Over vemogens verbruik.
In gemiddeld gebruik is de processor de meeste tijd in idle status (Desktop en veel (web)servers). Dan geldt toegevoegde functionaliteit is extra transistors is extra lekstroom. Is extra vermogen.

Persoonlijk vind ik het jammer dat de beste processors nu weg of bijna weg zijn. Zijnde Alpha G5 etc. Ik hoop dat de opkommende landen (India en China) een keer een betere processor zullen uitbrengen. Sneller, zuiniger etc. Want dat is met de huidige technologie mogelijk. Zie bv de MIPS en ARM chips tav vermogensverbruik. En de power 5 voor snelheid.

Door Wouter Tinus, donderdag 28 september 2006 09:27

Score: 2
Ik denk dat Apple anders bewezen heeft. Ze gebruiken al de derde processor in hun Mac type. Eerst 68000 familie daarna PowerPC en nu x86.
De overstap van 68000 naar PowerPC verliep rampzalig en de stap naar x86 is alleen maar soepel verlopen omdat het systeem via emulatie volledig backwards compatible bleef. Bovendien was het voordeel van x86 boven PowerPC zo groot dat het niet eens grappig meer was. Er is echter helemaal geen indicatie dat een x86-ontwerp zonder 16-bit mode of x87-eenheid ook maar 1% sneller zou zijn dan degene die we nu hebben, dus er is niet echt een motivatie om de compatibiliteit te breken.
Dan geldt toegevoegde functionaliteit is extra transistors is extra lekstroom. Is extra vermogen.
Het blijft een afweging, maar als een ongewijzigde 45nm-versie bijvoorbeeld 20% zuiniger is dan de 65nm-versie en men vervolgens 10% meer gaat gebruiken door nieuwe functionaliteit (een grove overschatting voor een paar nieuwe instructies trouwens) dan heb je netto nog steeds een zuinigere chip. Het zou me trouwens niets verbazen als SSE4 ook al in het huidige ontwerp zit, maar dan alleen voor testdoeleinden.
Persoonlijk vind ik het jammer dat de beste processors nu weg of bijna weg zijn. Zijnde Alpha G5 etc. Ik hoop dat de opkommende landen (India en China) een keer een betere processor zullen uitbrengen. Sneller, zuiniger etc. Want dat is met de huidige technologie mogelijk. Zie bv de MIPS en ARM chips tav vermogensverbruik. En de power 5 voor snelheid.
De 'beste processors' zijn mijns inziens degenen met een goede verhouding tussen prijs, prestaties en verbruik. Voor consumenten zijn dat op dit moment gewoon x86-chips. Andere instructiesets hebben geen magische voordelen die ze 'beter' zouden maken. Denk je bijvoorbeeld dat een ARM nog zo zuinig is als je hem even snel maakt als een Core 2? Of dat een Power nog zo goed presteert als hij voor 200 euro (of nog goedkoper) verkocht moet kunnen worden en maar 65W mag verbruiken? Ik weet wel zeker van niet: het zijn chips gemaakt voor andere markten met andere doelstellingen, en dat zijn veel belangrijkere verschillen dan de instructieset.

Door ddbruijn, donderdag 28 september 2006 09:59

Score: 1
Er is echter helemaal geen indicatie is dat een x86-ontwerp zonder 16-bit mode of x87-eenheid ook maar 1% sneller zou zijn dan degene die we nu hebben, dus er is niet echt een motivatie om de compatibiliteit te breken.
Dat komt omdat de 32-bit en 64-bit modes gebaseerd zijn op die 16-bit modus.
x87 wordt trouwens ook al geemuleerd op een P4, en waarschijnlijk ook in de Core2, is al niet echt meer geimplementeerd dus, behalve in microcode in de decoder. SSE2 is de 'native' FPU nu (mede daarom de slechte x87-prestaties van de P4, maar SSE2 is juist supersnel, zelfs sneller dan Core2 soms).

Maargoed, het punt is dus dat die 32-bit en 64-bit modus zo ontworpen zijn dat er weinig verschil is. Daarom is het niet zo erg dat er ook 16-bit op zit.
Maar dan bekijk je het probleem dus van de verkeerde kant. De 32-bit en 64-bit modes van de x86 zijn namelijk behoorlijk zwak en onelegant ('Een space-shuttle besturen met een pincet'). Als je kijkt naar PowerPC of andere 32/64-bit processors, zie je dat die door de jaren eigenlijk altijd betere IPC, performance-per-watt en meer van dat soort fratsen hadden, mede doordat de instructieset veel efficienter was ontworpen, en daarom de processor kleiner kon zijn. Minder grote decoders, kortere pipelines etc.
Helaas zagen Motorola en IBM het niet meer zitten om de PowerPC nog verder door te ontwikkelen als een desktop-processor, omdat de markt daar te klein voor was.
Zelfs de Itanium van Intel zelf is al efficienter... alleen merk je dat niet zo, omdat ze daar van die hele grote serverchips van bouwen met veel cache en 256-bit bussen etc. Maar puur de core van een Itanium is wel een stuk kleiner dan van een moderne x86, en dat is ook bij multicore straks veel interessanter. Je kunt er namelijk veel meer van op 1 die krijgen.

Vanuit dat oogpunt lijkt het me dus wel een goede zet om gewoon de legacy vaarwel te zeggen en opnieuw te beginnen. x86 heeft al die jaren nooit echt aan de top gestaan, ze hadden vooral een schaalvoordeel, waardoor Intel meer R&D erin kon stoppen en de processors dus beter leken dan dat ze eigenlijk waren.
Als je een nieuwe procesor zou ontwerpen met de R&D-mogelijkheden van de x86, dan zou je waarschijnlijk een aardige sprong voorwaarts kunnen maken.

Door Wouter Tinus, donderdag 28 september 2006 12:01

Score: 2
Als je een nieuwe procesor zou ontwerpen met de R&D-mogelijkheden van de x86, dan zou je waarschijnlijk een aardige sprong voorwaarts kunnen maken.
Misschien, maar dit is een volstrekt onrealistisch scenario. Je hebt niet het R&D-budget van x86 als je niet zo groot bent als x86, en geen enkel theoretisch voordeel in je architectuur gaat je helpen om marktaandeel te winnen. Intel zelf maakt nog de beste kans met Itanium, maar zelfs daar is pijnlijk duidelijk hoe de verhoudingen liggen qua mankracht en budget: Conroe is een handgemaakt meesterwerkje qua layout en circuits, terwijl grote delen van Montecito door software in elkaar zijn gezet. En dat is goed te merken aan de maximale kloksnelheid en fysieke afmetingen van beide cores.

Door iceblink, donderdag 28 september 2006 08:26

Score: 1
dotproduct heet in het Nederlands inwendig product of kortweg inproduct ;)

http://nl.wikipedia.org/wiki/Inproduct

Door MneoreJ, donderdag 28 september 2006 08:36

Score: 2
Eerst hadden we CISC processoren. Daarna kwam RISC, met veel eenvoudigere instructiesets. RISC werd toen gebruikt als basis om een CISC processor op te implementeren... en het word nu alleen maar CISCeriger, alleen zijn de instructies nu zodanig dat ze van je CPU een halve dedicated vectoreenheid maken. Dat is met name interessant omdat we nu ook de drive naar multicore hebben: je kunt vectorberekeningen parallel uitvoeren met "gewone" instructies. Je vraagt je dan toch af of CPU en GPU uiteindelijk niet weer dichter naar elkaar toe gaan groeien, na heel lang gescheiden te zijn geweest.

Door botervlieg, donderdag 28 september 2006 15:40

Score: 1
Ja, dat is het probleem nu net, alles blijft constant evolueren van centralisatie naar decentralisatie over periodes van 10-20 jaar. Maar nu we eindelijk evolueren naar multicore en parallel processing vind ik het een nogal rare keuze om 'grafische' instructies, of zoveel instructies in een cpu te stoppen.
Ik zou liever een nog meer gedecentraliseerde, modulaire structuur zien, een nieuw soort mobo waar je naar gelang het soort gebruik, cpu's, gpu's, physics units, dsp ... etc instopt.Zou toch handig zijn, je bouwt je computer naar eigen wens. Ben je eerder een gamer of 3d designer dan stop je er een paar grafische cores in, ben je bezig met audio processing, dsp cores ...

en die processing units zouden er dan kunnen uitzien als die van HAL 9000, ipv die onhandige sockets en wanorde in je computer kast :)

Door eshiz, donderdag 28 september 2006 09:34

Score: 0
Even een reactie op het plaatje... mis ik niet het 130nm procedé?

Door Wouter Tinus, donderdag 28 september 2006 09:36

Score: 1
In de Northwood zijn geen nieuwe instructies toegevoegd.

Door ernstblaauw, donderdag 28 september 2006 09:37

Score: 0
Kan AMD nu ook gebruik maken van deze 'SSE4'? Of is dit nog niet geregeld in bestaande overeenkomsten tussen de bedrijven?

Door Countess, donderdag 28 september 2006 10:01

Score: 0
volgens mij mogen ze er idd al gebruik van maken.
maar ik zou het nog niet en AMD's aankomende CPUs verwachten. dit soort dingen in je ontwerp opnemen kost tijd, tijd die AMD niet kwijt wil raken.

Door SuperDre, donderdag 28 september 2006 09:54

Score: 1
Is leuk en aardig, maar hoe goed worden nu de huidige SSE1-3 al gebruikt?

Door Countess, donderdag 28 september 2006 09:57

Score: 0
2 word zeker een hoop gebruikt. (en waarom ook niet, elke beetje modern CPU heeft het)
3 nog een flink stuk minder maar ook daar zie je verbetering.
maar over het algemeen duur het jaren voor het wijd verbreid is.
van de andere kant de applicaties die er echt veel baad bij hebben zijn er meestal een stuk sneller mee (denk aan photo shop en 3d max bv)

Door allih, donderdag 28 september 2006 15:45

Score: 0
Elk software pakket waarop staat dat het minstens een pentium 3 800mhz of compatible processor nodig heeft, heeft geen SSE2.

SSE werd in de pentium 3 geintroduceerd. De programma's die SSE2 gebruiken zullen dus of alles dubble moeten schrijven of de minimum eisen moeten verhogen naar pentium 4 of compatible.

Mac OSX gebruikt SSE3.

Door Left, donderdag 28 september 2006 09:56

Score: 0
Dit zijn echt hele handige aanvullingen op de instructieset, niet alleen voor grafische applicaties. Verbazingwekkend inderdaad dat deze nog niet tot de instructieset behoorden.

Jammer alleen dat het nog tot 2008 duurt voordat cpu's met SSE4 op de markt komen. En daarna nog een hele tijd voordat er software is die van SSE4 gebruik maakt.

Door Steephh, donderdag 28 september 2006 09:58

Score: 0
En als je je E6600 hoger klokt dan 3,1 GHz dan is je videokaart bij gamen weer de bottleneck.. Dus al dat gelul over dat videokaarten sneller zijn dan CPU's.. Ik geloof er niet in.

Door AHBdV, donderdag 28 september 2006 10:26

Score: 0
Ongelooflijk onnozel. Wat de bottleneck in je systeem is zegt helemaal NIETS over de prestaties van CPU en GPU op elkaar vlak.

De vidoekaart is de bottleneck omdat de videokaart vrijwel al het renderwerk doet, hetgeen nog altijd 90% is van wat er in een spel gedaan moet worden.

Jammer dat de CPU vaak een beetje idle staat te wezen terwijl de GPU aan het werk is... maar als je de CPU meer renderwerk zou laten doen, dan zou de framerate alleen maar slechter worden.

Door dangerpaki, donderdag 28 september 2006 10:40

Score: 0
je kan niet een bepaalde processor met een grafische chip vergelijken, er spelen namelijk andere factoren mee. als je op 640x480 gaat draaien dan is je videkaart niet meer het bottlenek (tenzij je een hele langezame hebt) maar loop je eerder tegen de grens van je cpu aan.

andersom als je een cpu van niet zoveel hebt maar je draait op laten we zeggen hd resoluties dan komt je vidkaart op de bottlenek aan.

het is dus pas te zeggen als je erbij zet welke settings je gebruikt
«  1  2  »

Op dit item kan niet meer gereageerd worden.

Volgende: Steve Wozniak schrijft het Apple-verhaal op 10:04
Vorige: Nieuwe exploits voor Powerpoint in het wild 23:59
Powered by True
RSS VNU Media logo
© 1998 - 2008 Tweakers.net - Alle rechten voorbehouden
Uitgever van: