Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 22 reacties
Bron: The Register

The Register heeft op IDF het nieuws opgepikt dat Intel in de G1-stepping van de Prescott-core twee instructies heeft toegevoegd die de compatibliteit met de AMD64-specs compleet maken. Het gaat om LAHF en SAHF, beide bedoeld om bepaalde statusinformatie uit te lezen. Deze twee zijn door AMD pas in een late revisie van de specificatie toegevoegd en derhalve niet door Intel overgenomen tijdens het ontwerpen van de Prescott. Het gevolg is een kleine incompatibiliteit, die men tot nu toe niet belangrijk genoeg vond om op te lossen. De G1-stepping met de extra instructies zal echter vanaf 14 november verkocht worden. Behalve de nieuwe revisie van de chip is er ook een nieuw BIOS nodig om van de instructies gebruik te kunnen maken. Hoewel de volledige compatibiliteit tussen AMD64 en EM64T voor Prescott een beetje als mosterd na de maaltijd komt, betekent deze zet waarschijnlijk wel dat dezelfde verbeteringen ook in de toekomstige 65nm-chips zijn opgenomen, en dat is natuurlijk wel goed nieuws.

Intel Prescott die (450)
Moderatie-faq Wijzig weergave

Reacties (22)

ik ben benieuwd of er in de nieuwe architectuur van intel (merom, conroe enzo) ook nieuwe instructies toegevoegd worden. kan me zo voorstellen dat er qua SIMD instructies/vector bewerkingen/SSE iets gewijzigd is.

AMD zal dan wel weer volgen net zoals AMD ook later haar SSE implementatie aanvulde met de SSE3 addities van Intel. dit is ook geen probleem voor Intel want AMD en Intel hebben een cross license overeenkomst voor zover ik begrepen heb.

uit de sheets die ik gezien heb begrijp ik echter dat de Merom/Conroe ISA van buitenaf gewoon downwards compatible met EM64T zal blijven. maar dit houdt Intel natuurlijk niet tegen SSE-4 achtige zaken toe te voegen (superset).

een bedrijf als Apple zou het niet erg vinden als eerste deze Merom/Conroe extensies in haar EM64T binaries te kunnen benutten. Apple heeft namelijk niet te maken met x86 legacy die teruggaat naar de jaren tachtig van de vorige eeuw. in Apple developer kringen wordt bovendien het gemis van Altivec (SIMD van powerpc G4 en hoger) nogal betreurd; SSE-4 zou daar wellicht wat verlichting bieden (as if intel cares ;)
Er zullen sowieso extra instructies voor Vanderpool en LaGrande worden toegevoegd, maar die komen ook al in de 65nm-Netburst. Er gaan geruchten over Rockton-instructies voor Merom, maar voor zover ik weet is er nog niets bekend over iets nieuws op multimediagebied.
Het grootste Athlon X64 probleem voor gebruikers en developers is op dit moment helaas niet de compatibiliteit van de AMD64/EMT64 inplementatie maar de anti-AMD optimering van Intels compilers (versie 8.0 en 8.1). :( Intel is, zoals bekend, marktleider met haar compilers (NB hoewel er ook zeer goede GNU compilers zijn, maar de Intel compilers werken gewoon erg snel), maar Intels compilers blijken moedwillig AMD processoren te benadelen; de /N en /P-flags (voor de Prescott) functioneren niet bij de laatste Athlon 64 en Opterons hoewel die daar beslist geschikt voor zijn (en ook SSE3 ondersteunen). De /P flag zou immers met deze Athlon 64's goed moeten werken maar doet dat niet tenzij, zoals de vossen van Heise (CT) weer eens hebben ontdekt (staat in de Duitse versie van CT, nummer 16), je uit de code het stukje verwijderd wat het processortype opvraagt! Dan blijkt met dezelfde compiler de Athlon64 plots 20 % sneller te lopen (SPEC2000-Benchmark), en dat ligt dan niet eens aan SSE3 (bij deze test) maar aan de andere optimeringen! Hebben ze bij AMD dus inderdaad gelijk als ze zeggen dat Intel (al lang trouwens) op oneerlijke wijze AMD benadeelt...

edit: het stukje uit CT staat ook op het web:
http://www.heise.de/ct/05/16/019/default.shtml
onder 'Wer suchet...'
Vreemd genoeg heb ik dat zelf niet kunnen reproduceren. Ik heb ook de Intel Compiler 8.1 gebruikt, maar het aanpassen van de CPU-check maakte geen meetbaar verschil op een Athlon XP of Athlon64.
Overigens was de compiler van Visual Studio.NET 2003 nog een stuk sneller.
Ik ben het er ook niet mee eens dat Intel de marktleider is. Volgens mij wordt VS veel meer gebruikt, zeker aangezien de laatste paar versies in bijna alle gevallen sneller zijn dan de Intel-compiler.
Vroeger was het altijd een must als je pc IBM (Iees: intel) compatible was maar nu even niet. Zeg is jouw pc wel AMD compatible..?? ;) Toch goed dat ze bij AMD innovatief bezig zijn..
Ik weet dat 'innovatief' een modewoord is, dat men te pas en te onpas wil gebruiken, maar hier is het echt niet op z'n plaats.
64-bit processors zijn niet conceptueel anders dan processors van 32, 16, 8 bits, of wat dan ook.
Het is 'meer van hetzelfde'. Net als een vrachtwagen met 8 wielen in plaats van 4.
Verder waren er in de jaren 80 al 64-bit processors, dus deze AMD is nogal mosterd na de maaltijd.
Tenslotte had Intel ook al eerder een moderne 64-bit processor op de markt dan AMD, namelijk de Itanium. Deze is ook een stuk innovatiever dan de AMD, bijvoorbeeld omdat deze het nieuwe concept van EPIC invoert, met een speciale instructieset waarbij instructies in bundels van 3 worden verwerkt.

AMD doet gewoon het trucje van Intel uit de jaren 80 met de 386 nog eens dunnetjes over. Innovatie? Vind ik niet, ik had het zelf ook kunnen bedenken.
Het is wel slim gebleken, omdat een CPU met goede 32-bit compatibiliteit de overgang naar 64-bit veel makkelijker maakt, en mensen nou eenmaal liever een korte-termijn oplossing hebben dan een lange-termijn oplossing. Op de uitvoering valt ook weinig aan te merken, de Athlon64 is gewoon een prima processor, zowel in 32 als in 64 bit.
Tenslotte had Intel ook al eerder een moderne 64-bit processor op de markt dan AMD, namelijk de Itanium.
beetje jammer dat het een vierkant mislukte en uitgelachen processor was, partner HP heeft toen zelfs het zinkende schip verlaten.
Was? De itanium is nog volop in leven, en de nieuwste telg, de Montecito, heeft nu (terwijl deze nog niet eens leverbaar is) al meer order staan dan alle voorgaande verkochte Itaniums bij elkaar. De Itanium is nog steeds volop in leven en zeker wanneer CSI rond 2007 er echt komt, dan gaat de Itanium z'n eerste echte sprongen maken. De Itanium is een zeer snelle cpu, maar is langzaam omdat men er software op draait die er niet voor gemaakt is, het is nu eenmaal géén doodnormale x86 cpu, maar gebruikt de EPIC instructieset, waar ddbruijn dus op doelt. Je moet niet zomaar ergens over oordelen als je niet weet waar je over praat.
Laten we zeggen dat dit het sleutelpunt is geworden waar Intel moet onderdoen aan zijn rivaal die jaren terug maar matig onthaald werd. Dit is het ultieme bewijs dat het stagneren van grote bedrijven vaak de mankementen zijn tegenover beginnende jonge bedrijven die uiteindelijk de overhand weten te nemen door hun innovativiteit. Good work AMD zou ik zo zeggen, afgang Intel om AMD compatible te moeten zijn.
Afgang? Amd moet net zo hard haar best doen om Intel compatible te zijn als het om SSE3 gaat.

Dat heb je nou eenmaal met specificacties.
Blijf het grappig vinden.

AMD dat vroeger Intel chips doormidden zaagde om ze te kopieeren dat nu instructies heeft die Intel overneemt.
Sorry hoor, maar AMD was echt wel de eerste met AMD64 processoren. De versie van XP64 heeft ook zolang op zich laten wachten omdat Microsoft heeft gewacht totdat Intel klaar was met zijn onvolledige product. Onvolledigheid is de laatste tijd bijna standaard bij Intel. Is ook nu weer zo met de dualcore processors. Die van AMD zijn ten eerste volledig ontwikkeld en ten tweede zijn ze ook nog beter. Die van Intel zijn provisorische oplossingen om niet een grotere deuk op te lopen, dan dat ze al hadden opgelopen.
En nog even het volgende, Intel heeft en had een 64bits processor, die is door de markt niet geaccepteerd. Microsoft heeft daarbij Intel laten weten, dat ze niet van plan waren om NOG een 64bits OS te maken, die speciaal voor Intel processoren geschikt zou zijn.
Intel heeft moeten toegeven, dat de Itanium toch niet geschikt genoeg is voor consumenten, daar hierdoor alle software opnieuw geschreven zou moeten worden. Microsoft heeft daarbij ook al de support voor de Itanium versie van XP laten varen.
Intel kwam met IA64, leuke voor 64bits applicaties..geschreven foor IA64 maar helaas was er emulatie nodig om 32bits software te kunnen draaien, en emulatie maakte het traag als stroop!

AMD had gewoon 32bits..en voegde daar een 64bits extensie set bij... and voila.. en 64bits processor die ook 32bits aankan. Zonder snelheids verlies..

Marktwerking he, voor dat alle bedrijven all hun software omgezet hebben naar IA64 is duurder dan gewoon AMD64bits te gaan draaien met behoudt van oudere software.
Sorry hoor, maar AMD was echt wel de eerste met AMD64 processoren.
Sterker nog: AMD is de enige met AMD64 processoren :+
emulatie maakte het traag als stroop!
Met de emulatietechnologie uit de jaren 60 wel ja. Maar sindsdien is er een hoop gebeurd. Apple stapt nu voor de tweede keer over naar een nieuwe architectuur, en is daardoor gedwongen om de oude architectuur te emuleren, om backward-compatibility te garanderen. Verder zijn er al eerder Windows-versies op non-x86 geweest, zoals bijvoorbeeld de DEC Alpha, en daar was het ook mogelijk om x86-code te draaien.
Natuurlijk is emulatie niet zo snel als native code, maar met de hedendaagse technologie is het een prima bruikbare oplossing. Het enige probleem bij IA64 was dat het tot Service Pack 2 duurde totdat die hedendaagse technologie beschikbaar was voor het platform. Dat bleek dus te laat.
Reden dat Intel geen eigen spec heeft ontwikkeld, komt voort uit de eis van Microsoft: deze wilde niet nog een platform ondersteunen en heeft Intel mede gedeelt dat wanneer ze een 64 bit processor bouwen, hij compatible moet zijn met de AMD64 spec, waarvoor Microsoft al tijden voor aan het ontwikkelen was (Windows XP 64 Bit (x86) onder andere).

Intel is dus niet "lief" geweest, AMD is Intel gewoon voor geweest en Intel moet daardoor de consequenties voor "lief" nemen. ;)
in een markteconomie bestaat niet zoiets als goodwill tussen concurrenten. zoals eerder aangehaald is is de ondersteuning voor amd64 instructieset groter dan voor de 64 bit extensions van Intel. het feit dat Intel een groter marktaandeel heeft in het 32bit segment is niet relevant.

de software developer heeft zijn keuze gemaakt. dit gebaseerd op wie er eerder was en potentie van de technologische ontwikkeling.
En wat heb ik als consument eraan?
Wat betekend dat AMD compatible?
De software zal dus beter op beide systemen kunnen draaien, wordt makkelijker te ontwikkelen (geodkoper?).. Maar direct, als consument, merk je er écht niks van...
Ik heb altijd al geweten dat Intel voor AMD werkte!
het blijft imposant om zo'n klein vierkantje vol techniek te zien waar je vroeger een kast / huis vol transistoren etc nodig voor had.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True