Yamhill Technology: Intel's geheime wapen?

In Hillsboro, Oregon, werkt een klein team Intel engineers in stilte aan een processortechnologie, waarvan de chipgigant hoopt deze nooit in te moeten zetten. Dat schrijft Mercury Center in een artikel, waarin ondermeer een voormalig Intel-ingenieur - die anoniem wou blijven - en een paar analisten hun licht laten schijnen op 'Yamhill Technology' (YT), zoals Intel's x86-64 ontwikkeling genoemd wordt.

Het artikel vertelt dat in een volgende versie van Intel's Pentium processor x86-64 extensies ingebouwd zullen zijn en dat, wanneer de markt en de concurrentie Intel daartoe nopen, de Yamhill code alsnog geactiveerd zal worden in 2003 of 2004. Dit zou het geval kunnen zijn wanneer het succes van de volgende 64-bits Itanium processor (McKinley) achterblijft op de verwachtingen.

Het verwarrende in dit verhaal is echter de codenaam Prescott die de desbetreffende chip zou dragen, want dat was ook de codenaam voor de 0,18 micron Willamette in Socket478 uitvoering: een processor die nu door de 0,13 micron Northwood langzaam maar zeker vervangen wordt.

Analisten bevestigen dat het zeer aannemelijk is dat Intel een dergelijk ontwerp achter de hand houdt. Dit omdat volgens hen Intel het risico van een tegenvallend succes van de 64-bits Itanium, zonder backupplan, niet kan lopen. Intel zelf weigert ieder commentaar op het artikel, met als argument "dat men nooit uitspraken doet over producten die niet aangekondigd zijn". Maar volgens de analisten moet Intel zoiets ook wel ontkennen, omdat bevestiging ervan het beeld van Intel's vertrouwen in - en daarmee het succes van - de Itanium zou kunnen ondermijnen:

Intel's decision to back the novel Itanium architecture had upset a small group of Intel engineers in Oregon, who preferred to build on the x86 legacy. When AMD released the specifications of its upcoming 64-bit chips in the summer of 2000, these ``cowboy'' engineers decided that Intel needed to match its rival. They began developing their own 64-bit extensions to the Pentium line, making sure the code was compatible with AMD's design.

The Oregon team's initiative inflamed the feud between them and the Santa Clara team developing the Itanium, according to former engineers. But top executives, including Chief Executive Craig Barrett, reluctantly decided to support Yamhill development in addition to Itanium.

Reacties (41)

[I.R. Overclocked]

Is dit een soort Sledgehammer/Clawhammer verhaal, of zit ik er weer eens helemaal naast?
(sorry dat ik meteen een vergelijking maak met AMD btw...)

[TheGhostInc]

Inderdaad, dit is de directe tegenhanger van de hammer serie van Amd. Die wel doorbouwd op het succes van x86-32 processoren.
Zoals in het stukje ook naar voren komt is het het backupplan voor de IA64 technologie.

* 786562 TheGhostInc
Daarnaast zou het verschil tussen de Hammer's en de IA64 processoren weleens mee kunnen gaan vallen, elk OS zal in beide smaken waarschijnlijk uitkomen, en belangrijke cq. zware software zal waarschijnlijk ook voor beide architecturen uitkomen.
Ik vraag me wel af hoeveel verschil er tussen zit, is het alleen een andere compiler, of moet er veel meer veranderen.

[Femme]

* TheGhostInc vraagt zich af of de IA64 architectuur wel kan floppen, als Intel nu 80% van de markt in handen heeft, dan zal dat dadelijk altijd nog een meerderheid zijn, ze zullen dus redelijk wat IA64 machines gaan verkopen.

Het probleem waar Intel mee kampt is dat de Itanium momenteel niet van de grond wil komen terwijl ze over één à twee jaar een goed presterende x86 opvolger moeten hebben vanwege het simpele feit dat de beperkingen van 32-bit adressering dan 32-bit x86 processors ongeschikt maken voor gebruik in servers. Tegen die tijd heeft een beetje server meer dan 4GB RAM nodig.

AMD heeft in principe een oplossing voor het probleem en deze oplossing kan alle oude software draaien. Intel heeft een compleet nieuwe architectuur waar nog weinig software voor is en die momenteel nog niet optimaal presteert. Stel dat de Itanium om wat voor reden dan ook faalt, dan heeft Intel over een paar jaar een probleem.

Overigens vind ik dat ze dan beter de Alpha uit de kast kunnen trekken dat een 64-bit x86 processor te ontwerpen. De Alpha is het meest vooruitstrevende RISC design van dit moment. De Alpha heeft zich allang bewezen, presteert goed en er waren ook al voldoende plannen om de architectuur in de toekomst verder te ontwikkelen. Als ze nou gewoon de IA-64 dumpen en voortburderen op de Alpha is het hele probleem opgelost denk ik dan .

[EfBe]

Intel's Itanium chip is bedoeld voor het wennen aan de EPIC architectuur. Dat de chip 64bit is is logisch: waarom zou je hem geen 64bit maken? Dat het een lang traject is is ook logisch: alles en iedereen is vastgeroest in x86. Het is onnozel te denken dat Intel de EPIC architectuur gaat vervangen door een x86-64 variant en zo door blijft modderen met de x86 instructieset. Daar is de rek allang uit. Intel weet dat, en AMD weet dat ook.

[mr_a]

Als ze nou gewoon de IA-64 dumpen en voortburderen op de Alpha is het hele probleem opgelost denk ik dan .

Gezien hun partnership met HP denk ik dan niet dat dat tot de mogelijkheden behoort.

Eigenlijk vind ik het wel een beetje jammer en oneerlijk dat iedereen schijnt te vergeten dat de Itanium net zo veel HP is als Intel.

Hewlett-Packard heeft het grondontwerp gemaakt, omdat ze een opvolger voor PA-RISC wouden hebben. Inmiddels hebben ze zowel Linux als hun eigen HP-UX naar het platform geport. HP-UX heeft nu voor 100% ondersteuning voor Itanium, m.a.w. Itanium is in te zetten in een productieomgeving. Dat is echt geen kleine commitment geweest!

HP heeft dan ook precies dezelfde problemen die Intel heeft met de acceptatie: huidige PA-RISC systemen zijn sneller dan Itanium. HP heeft zelf een overgangsperiode van 2 jaar in gedachten: in de komende twee jaar gaat IA-64 meerdere factoren beter presteren terwijl er slechts enkele speed-grades voor het "oude" platform zullen zijn. HP wil dat hun grote klanten nu Itanium systemen aanschaffen en er aan gaan wennen. Voor ieder verkocht HP Itanium systeem verschaft HP 50% korting voor een vergelijkbaar HP McKinley systeem zodra ze er zijn.

Over twee jaar is kan er bij de aanschaf van een nieuw HP-UX systeem geen twijfel: je wilt en neemt IA-64. Hetzelfde misschien voor de zwaardere Windows servers, maar dat hangt af van hoe goed dat gaat werken (is nu nog niet bekend).

[Cookie]

Het probleem waar Intel mee kampt is dat de Itanium momenteel niet van de grond wil komen

Daarom gaat Jaguar Racing ook zijn nieuwe Formule1 wagen daarmee ontwikkelen en er o.a. windtunnelstudies mee simuleren:
http://www.computing.vnunet.com/News/1128452
Het is namelijk niet de bedoeling dat zo'n racewagen van de grond los komt

[SG]

* TheGhostInc vraagt zich af of de IA64 architectuur wel kan floppen, als Intel nu 80% van de markt in handen heeft, dan zal dat dadelijk altijd nog een meerderheid zijn, ze zullen dus redelijk wat IA64 machines gaan verkopen

Wat vertegenwoordigd die 80% de desktopmarkt.? In de high-end/enterprise servermarkt spelen vele platformen mee dus daar is het geen 80% of het is dan wel erg toevallig want dan hebben die anderen maar 20% te verdelen Sun sparc etc. En AMD moet daar nog beginnen met de Sledge hammer.

[EfBe]

De Itanium is wel 64bit maar dat is niet het belangrijkste. Wat het belangrijkste is is de EPIC instructieset en de technologie op de chip die daarmee is gemoeid. _DAT_ is het belangrijkste van de itanium en Intel's next-gen core technologie. Dat kost echter jaren voordat dat gesettled is en wellicht dat ze iets inzetten om dat gat op te vullen, maar ik vind het onwaarschijnlijk.

[Anoniem: 8504]

Het zou wel heel jammer zijn als ze weer terug gaan naar 'simpel' de bit-bus te verbreden. Ik ben grote voorstander van EPIC, kunnen we eindelijk eens af van de oude architectuur.
Ik zou het een grote achteruitgang vinden als je weer terug moet naar X86-64...

Go itanium go!!

[35MHz OC]

Het is heel aardig dat de EPIC instructieset veel paralellisme kent. Het zou theoretisch voor een gigantische IPC en efficientie moeten zorgen. Echter heeft Intel op dit moment met de Itanium processorfamilie een peperduur, ongevraagd en tegenvallend platform.

Het ironische van de Itanium is dat in de 7 jaar van ontwikkeling, de technologie het beest reeds lang achter zich heeft gelaten.

Huidige (in the near future) x86 processors kunnen met eenvoudige extensies efficient 64 bit programmacode uitvoeren. Intern zijn alle x86 processors RISC-processors geworden. Alle X86 instructies worden afgebroken tot micro-ops (RISC instructies) en dan door de RISC-core verwerkt.

Paralellisme hoeft niet meer in de code gecompileerd te worden (zoals bij Itanium), want met de huidige schedulers met out of order execution in combinatie met simultanious multithreading heb je al een processor die heel wat paralell kan verwerken.

Met de komende generatie aan uitbreidingen op de x86 instructieset (zoals de opvolgers van 3DNOW! en SSE2) kan wel eens blijken dat dat x86 heel erg levend is.

x86 wordt als verouderd en achterhaald beschouwd, maar dat is populistisch gedacht, het komt uit de jaren 70 dus is het rommel. Echter is de instructieset tegenwoordig een abstractie. Meer een kader voor het programmeermodel, dan een beperking in de processortechnologie.

x86 doet +/- 25 jaar na zijn "geboorte" meer dan waar het in de jaren 70 voor werd ontworpen en het eind is nog niet inzicht.

Laat Intel eerst maar eens bewijzen dat we echt overal Itanium nodig hebben. Voor echt superzware toepassingen kan het best een excellent platform zijn. Maar in dergelijke situaties gaat het maar om een ding en dat is prestatie. Zaken als gebruiksvriendelijkheid en economische overwegingen zijn er aan ondergeschikt.

x86-64 is een technologie die overal inzetbaar is. Van laptop tot mid-range server. Van dektop tot spelconsole. Ik zie deze technologie een gouden toekomst tegemoet zien. Itanium is te gecompliceerd om er een consumentenprocessor van te klutsen.

Yamhill zou wel eens de zijden draad kunnen zijn waar Intel zich aan vast kan houden....

[SnowDude]

Het grootste probleem waar intel nu mee zit is de compiler voor de itanium. Door die drievoudige pipe-line is een groot deel van de performance afhankelijk van de compiler. Want deze moet de op zo'n perfecte volgorde zetten dat de processor bij een mis predection niet zijn complete cache moet flushen. Ik denk dat de x86-64 bedoeld is als tussen stap voor de consument. Want bedrijven zullen eerder over stappen voor hun server op Itanium en ik denk dat consumenten pas over een jaar of 2 a 3 over gaan stappen op het EPIC platform.

[Anoniem: 45051]

Ja, je ziet het vaker. Goed idee, praktisch weinig nut.

Het is raar dat de x86 architectuur het zo lang heeft uitgehouden. Ik heb veel x86 (i386 + MMX + SSE) gecode en ook wat MIPS en 68K. Het lijkt me dat een MIPS-type proc veel makkelijker te decoderen en streamlinen is dan een x86. Maar intussen zijn die x86 procjes zo efficient aan 't worden met speculative execution, pre-fetching, etc. etc. dat er amper voor te coden valt, maar dat ze ook rete-efficient zijn geworden t.o.v. een meer RISCerige architectuur als Itanium, MIPS of PPC.

Probleem is (in 't kort, volgens mij) dat processor efficientie vaak niet zoveel meer afhangt van het basisidee (x-bits, risc/cisc), maar meer van bepaalde features (multimedia-instructie, snelle load/store van register state t.b.v. task-switching, cache-management, fsb-protocol en speed etc.) omdat nu eenmaal de meeste tijd verloren gaat aan "onzinnige" dingen (latency van geheugen, snel brekende pipelines, cache management, foute branch-prediction, etc.).

Omdat de oude I32-familie processoren zo'n "rotte" instructieset en basis hadden zijn die processoren beladen met truukjes om die worst goed te breien. In een MIPS, Alpha of Itanium platform kom je dat niet tegen. De code is duidelijk en vertelt de processor precies wat 'ie moet doen. Bij de x86 zit dat wel anders.

Raar dus, dat x86 + veel oplapwerk een stuk beter schijnt te presetern dan menig retegoed RISC design..

Tijd om eens beste van twee werelden te combineren lijkt me. Wel strak en simpel, maar eens niet bang zijn van variabele lengte instructies of unaligned memory accesses.

Michiel

[Anoniem: 18254]

Mocht iNTEL besluiten deze techniek in te zetten (omdat ze 'm nodig hebben) dan betekent dat AMD ze al verslagen heeft en ze dus te laat zijn.

[SnowDude]

Dat ben ik niet helemaal met je eens.
Ik denk eerder dat intel deze proc meer als tussen stap voor de "gewone" consumenten gaat inzetten. Want ik denk dat de AMD's eerder betaalbaar zijn dan de intel's.

[seef]

waarvan de chipgigant hoopt deze nooit in te moeten zetten

Moment.
Intel ontwikkelt dus een processor die beter is dan de 64-bits Itanium, maar ze hopen deze techniek nooit te zullen gebruiken? Dus als ik het goed begrijp worden deze gewoon weggeflikkerd als de Itanium wel slaagt. Dat is vreemd, je zou nl. denken dat ze hem dan als opvolger zouden gebruiken.

[Anoniem: 14842]

Natuurlijk niet.
Technisch gezien is deze processor inferieur aan de "echte" 64 bits variant. Deze zit zeg maar op het zelfde niveau als de 64 bits processor van AMD.

Daardoor zal het echter wel makkelijker (lees: goedkoper) zijn deze processor te maken. Als de "echte" 64 bits dus nog niet geschikt is voor de grote markt (te duur) kunnen ze deze nog inzetten als gulden middenweg.

Anders zou iedereen die een 64 bits proc. wil kopen maar niet het geld heeft wat Intel voor hun paradepaardje vraagt immers een AMD kopen. En dat is waarschijnlijk niet de bedoeling van Intel (gokje ).

EDIT:
Inderdaad, ik bedoelde met de "echte" 64 bits de pure 64 bits processor van Intel dus zonder x86 instructies. Deze is toch ook een stuk sneller met het 64 bits werk en veel trager met het 32 bits rekenen
/EDIT

[Femme]

Wat is er onecht aan een 64-bit x86 processor?

[Mentalist]

Wat is er onecht aan een 64-bit x86 processor?

Doelt ie met de "echte" 64 bits cpu niet op de cpu die Intel ook echt uitbrengt als 64 bits cpu? (da's de itanium toch?)

[ferdinand]

Ik denk dat ie er op doelt dat de IA64 architectuur niet alleen 64 bit is maar ook meteen een compleet nieuwe architectuur in plaats van wat AMD met zijn x86 64 doet.
Overigens denk ik dat deze x86 64 technologie misschien wel handig als een notebook processor.

[SG]

64bits houd in per bit 64 geleider baantjes voor de data bus van de ingang van de CPU ALU's van de core die dus per maximaal 64bits worden bewerkt ipv tot maar 32bit's bij IA32

Dus de core stages zijn 64bits en alle/meeste registers ook

'n int in 64bits modus is dus vaak 64bits en zorgt 64bits alignment voor de hoogste efficentie

'n 32bitter kan 4 8bits kleuren rondpompen
'n 64bitter kan 8 maal 8bits kleuren rond pompen
is in zo'n code geval 2x zo snel.

De huidige IA32 is nu de architectuur standaart X86 en IA64 is een totaal andere nieuwe architektuur (EPIC) die niet compatibel is.

Dus de hardware implementatie is totaal anders om native copatible te zijn moesten ze de IA32 appart in de core Implementeren dan krijg je Itanium EPIC core met 'n Netburst core er in.
Dit hebben ze bijvoorbeeld in het verleden gedaan toen ze van 8bits cores naar 16bitscores en naar 32bit cores met Cisc decoders met microcode naar Risc. En had de CPU 'n paar modusen om in te werken.
Om de "die" te bepeperken hebben ze het niet gedaan en die ballast overbord gegooid, kost DIe space.

De X86-64 is een echte 64bitter verwerkt data per 64bits net als de itanium. maar zijn implementatie architektuur is kompatibel met IA32 en kan dus Cascaded worden geimplementeerd,
lijkt iets op het crossbar foefje van nVidia kan 32bits 64bits en 128bit transfers aan simultaan. maar er zijn wel grote verschillen

De logic implementatie is hetzelfde dus van 32bits naar 64bits is eenvoudiger in één core te verwezenlijken.

De huidige compilers zijn IA32 optimized deze zijn eenvoudiger uit tebreiden naar x86-64
EPIC compilers worden van de grond af opnieuw gemaakt is dus moeilijker maar ze zijn er wel net zolang mee bezig geweest als de itanium zelf dus.

Er zal wel een performance verschil zijn tussen EPIC en x86 maar dat heeft met de logic architektuur en compilers te maken en niet met 64bits want dat hebben ze beide.

Dus hoe snel zijn ze met 64bits data te verwerken.

De kracht van de itanium zit hem in de Epic architektuur gekoppeld aan 64bits
De kracht van de hammer zit hem in sterk optimized x86 design en 64bits modus en IA32 native support.

[Anoniem: 45051]

'n 32bitter kan 4 8bits kleuren rondpompen
'n 64bitter kan 8 maal 8bits kleuren rond pompen
is in zo'n code geval 2x zo snel.

Da's niet helemaal waar. De 16/32/64/128 bit architectuur word namelijk vrij los door elkaar heen gebruikt.

Neem bijvoorbeeld de PS2, een 128-bit MIPS R5900 (van Toshiba als ik me niet vergis), dus hij heeft 128 bit registers. De memory bus is 32 bit (effectief 28, met de SPAD, UC, UCA bits bijgerekend), en de ALUs zijn 64 bit. Ja, wat is dit nou? Je kan 128 bit berekeningen doen (maar dan gebruik je beide 64-bit ALUs), de memory bus is 32 bit, en de ALUs 64.

Zelfde geldt voor Intel, op een Pentium MMX heb je 64 bit MMX registers zitten, op een 32-bit architectuur, een SSE omgeving (P3+?) heb je 128 bit vector-registers liggen wederom om een 32bit architectuur.

Het lijkt erop dat CPU-bakkers voor PC's de bit-wideness definitie gebruiken voor de adres-bus (dus, x86 = 32 of 36, Itanium/x86 = 64) omdat daar de hoeveelheid aan te spreken geheugen (databases, e.d.) belangrijk is.

Consoles gebruiken vaker de register-breedte en databus als specificaties. N64 had een 64 bit bus (en 32 bit registers als ik me goed herinner), maar werd dus een 64-bit console genoemd.

Anyway, bit-specs van processoren slaan nooit ergens op, ze verhogen ze op het moment dat ze *en* een plaats op de proc kunnen vinden waar ze meer bits hebben dan de directe concurrent *en* ze dit voordeel als marketing-punt willen aankaarten.

Uiteindelijk heb je zoveel verschillende pad-breedtes (regs, ALU(s), i-bus, d-bus) dat je altijd wel iets kan kiezen.

I64 over I32 is vooral data-bus, gekoppeld aan een nieuwe architectuur, totaal verschillend.

Moet trouwens zeggen, goede post SG, kan zien dat je weet waar je 't over hebt, alleen niet altijd even duidelijk.

I64 over I32 is vooral data-bus Uh, ja, nee, adres-bus dus, data pad is allang meer dan 32 bit.

[The Source]

Typisch Intel om op verschillende technologieën te wedden. Dit was ook al zo met hun RDRAM en DDR geheugen ondersteuning.

Als dit gerucht waar is dan willen ze het natuurlijk compatible houden met de x86-64 technologie van AMD. Daarvoor dient er dan een licentie van te zijn en die zal AMD met liefde afgeven... betekent enkel een breedere acceptatie van hun technologie.

[Cookie]

AMD's CEO Jerry "only real man have fabs" Sanders !!! zei tijdens eens meeting met analisten, 8 november vorig jaar het volgende:

"My biggest f3ar is that Intel will come out with a 32-bit processor with 64-bit extensions because it is the right thing to do,"

[SG]

Dit verhaal lijkt mij wel aannemelijk.
iNtel was met de komst van de Athlon best wel verrast vooral toen de PIII niet verder wou.
En de P4 had 'n lange aanloop start dus viel in den begin duidelijk tegen..

Dus aangezien itanium/McKinley totaal verschillendzijn tov de Hammer, maar de Hammer migratie veel makkelijk is alleen Hardeware, software kan later ivm de IA32 native compabiliteit. Heeft intel hiervoor geen directe tegen hanger.

De iTanium/McKinley zal net als de P4 een nog langere aanlooptijd hebben en als dat langer duurt dan intel verwacht had dan lopen ze klanten kwijt aan de X86-64 platform.

Dus dit bericht zegt mij als het waar is dat intel niet verrast wil worden mocht AMD succesvol zijn wat toch redelijk mogelijk is, en wil dat ook niet afwachten maar heeft dus maatregelen genomen door als backup plan 'n directe concurerende produkt achter de hand te houden zodat de Hammer niet die Deel markt compleet inneemt mocht die succesvol zijn dus intel wil dat risico niet lopen.

Lijkt op speculaas maar lijkt mij ook logisch mocht het waar zijn.2003/2004 wordt dus spannend.

Zo heeft intel 'n kleiner Risico en kan er ook de schade mee beperken om markt aandeel te behouden.
Itanium/McKinley kan dan Mocht de markt er nog niet aan toe zijn 'n langere aanloop nemen eer die doorbreekt.

Net als deaanlooptijd v/d P4 maar dan met een grotere tijd schaal om dat hier ook de software 'n rol speeld..(native OS & Apps)

De X86-64 vult 'n marktgat op tussen de IA32 & de IA64 Waar intel momenteel officieel geen produkt voor heeft

[Spice]

ja, check your resources zou ik zeggen. " Mercury Center" wasda d8 ik?
Kort oordeel van mijzelf (na 5 minuten zoeken: kritiek is welkom).
Volgens mij een soort "Gelderlander" (no offence kan van alles zijn). Met een bericht uit de omgeving. Zoiets als: "de door zwaluwen geteisterde aardbeienvelden zullen dit jaar een aanmerkelijke lagere opbrengst te zien geven" .
Zelfde context voor dit berichtje.

edit: "gelderlander" is een regionale krant (vul dus maar de jouwe in"

[Cookie]

En waarom zou een krant, gevestigd in de streek waar Intel's Headquarters staan en een ex-Intel engineer spreekt, dit uit z'n duim zuigen? Ook in Nederland komen bepaalde nieuwsitems eerder op de regionale TV-zenders...Ik kan verder alleen maar constateren dat vandaag alle grote PC-nieuwssites dit bericht overnemen.

Ik zou er niet raar van opkijken als 'De Gelderlander' bepaalde 'infoleaks' over Philips Semiconductors bijvoorbeeld of de Nuon, eerder heeft en plaatst dan een nationaal dagblad.

[jhead22]

Typisch de economie van tegenwoordig

Geld geld geld.. En of het product wel voldoet aan alle eisen, vragen of kwaliteit is minder belangrijk.

Die extra functie.. is de cpu dan opeens een stuk sneller wanneer dit wordt ingeschakeld Zou tof zijn als we t zelf kunnen inschakelen

//offtopic: Tis trouwens bedtijd

[Anoniem: 34136]

Wat een wazig artikel?

Er wordt iets gemaakt, maar dat wordt ook weer ontkend. Jaja......

[Anoniem: 2388]

nee man...het is gewoon een backupplan voor als de itanium enorm gaat zuigen. Dan kunnen ze dit inschakelen en dus eigenlijk AMD immiteren.

[Cyberwizzard]

Issut dan voor Intel dan niet slim om eerst uit te proberen of die 'publieke' core wel aan Intel's eigen verwachtingen voldoet voor een 64-bit core???
Mocht het resultaat tegenvallen dan kunnen ze beter meteen op het nieuwe design overstappen...