Az Intel keresztlicenc-szerződés megszegése miatt figyelmeztette az AMD-t

Intel

Az Intel tegnap hivatalosan bejelentette, hogy figyelmeztette az Advanced Micro Devices-t (AMD), mert álláspontja szerint az AMD feltehetően megsértette a két vállalat közt 2001-ben kötött keresztlicenc-szerződést azzal, hogy a licencet továbbadja a Global Foundries-nek. A Global Foundries az az újonan alapított vállalat, amely az AMD-től átveszi a processzorgyártást.

Az Intel úgy hiszi, hogy a korábban kötött szerződés értelmében a Global Foundries nem leányvállalata az AMD-nek, így az nem rendelkezik a 2001-ben a két vállalat közt megköttetett licenccel.

A bejelentés itt olvasható.

A HWSW szerint "Mindezek oda vezethetnek, figyelmeztet a cég, hogy az AMD 60 nap múlva elveszti a licenceket és ahhoz fűződő jogait, ha nem tudnak megegyezésre jutni a felek, vagy a szerződésszegés állapota nem szűnik meg. Ez egyet jelentene processzorai forgalmazásának leállásával. Az AMD szerint az Intel vádjai alaptalanok, és saját szellemi tulajdonának megvonásával fenyeget."

A cikk itt.

( bervi | 2009. 03. 17., k – 18:58 )

hát ha már gecizni akarnak, az intel szerintem szarabbul jöhet ki :)

"AMD licensed its x86-64 design to Intel, where it is marketed under the name Intel 64 (formerly EM64T). AMD's design replaced earlier attempts by Intel to design its own x86-64 extensions which had been referred to as IA-32e. As Intel licenses AMD the right to use the original x86 architecture (upon which AMD's x86-64 is based), these rival companies now rely on each other for 64-bit processor development. This has led to a case of mutually assured destruction should either company revoke its respective license.[2] Should such a scenario take place, AMD would no longer be authorized to produce any x86 processors, and Intel would no longer be authorized to produce x86-64 processors, forcing them back to the now-obsolete 32-bit x86 architecture."

"Windows NT 4.0 is the last major release of of Microsoft Windows to support the Alpha, MIPS or PowerPC CPU architectures. It remained in use by businesses for a number of years, despite Microsoft's many efforts to persuade customers to upgrade to Windows 2000 and newer versions."

Az NT kernel egyik tervezési célja volt az is, hogy könnyen portolható legyen az egyes architektúrák között, más kérdés, hogy mára az x86 és az x86_64 vált domináns platformmá.

----------------
Lvl86 Troll

Vista és WinServer közös kódbázisra épül, nem lenne nehéz portolni a WinServer-ből kihagyott dolgokat.

Csak gondolom ezért nem készítettek belőle portot:

"This edition was discontinued in early 2005, after Hewlett Packard, the last distributor of Itanium-based workstations, stopped selling Itanium systems marketed as 'workstations'.[22] As of July 2005, Windows XP 64-Bit Edition is no longer supported, and no further security updates were made available." [Wiki]

----------------
Lvl86 Troll

Igen, tisztában vagyok vele. Pedig csak egyszer kéne lenyelni az a békát, hogy mostantól emulátorral futtatjuk az x86 kódot és az új binárisokat már nem erre készítjük. Jó jit fordítós emulátortól talán 1-2 generációnyit lépne vissza a teljesítmény, ami már bőven használható szintet jelent.

Igazából csak eljátszottam azzal a gondolattal, hogy az említett két cég közül valamelyik kényszerből elkezd egy a mostani x86-os processzorokhoz hasonló kivitelű (desktop alaplapba, akár LGA775 vagy AM3 foglalatba rakható), de nem x86 ISA-t megvalósító processzormagot fejleszteni és hasonló árfekvésben piacra dobni. Szerintem egyébként nem is lenne túl nagy effort, csak a dekóder front-endet kell kicserélni a processzorban, az összes többi (cache, végrehajtóegységek, reorder buffer, TLB stb.) maradhatna változatlan. Ráadásul egy jó ISA esetén az új design validálása is sokkal egyszerűbb, mert nem kell az x86 összes régi legacy üzemmódját és ezek közötti állapotváltást implementálni majd ellenőrizni, hogy jó-e.
---
Linux is bad juju.

Igazából ami elhatározás kéne a részükről, hogy végre csináljanak egy rendes risc processzort, és felejtenék már el ezt a cisc-es hülyeséget.

Gcc-t felfejlesztenék, a piac terítése előtt egy jól megcsinált, jól optimalizált compilerrel a procijukhoz, ez ütne a piacon.

IMHO.

...izé, csak érdeklődöm, hogy miért olyan egyértelmű, hogy csak a RISC processzor lehet jó?

...nézzük...

RISC (Reduced Instruction Set Computer)
- Redukált (sokkal kevesebb) utasításkészlettel rendelkezik
- Elemi utasítások használhatók, de azt nagyon gyorsan képes végrehajtani
- Ugyan az utasítás végrehajtása gyors, a redukált (elemi) utasításokból sokat kell végrehajtani az adott feladat elvégzéséhez

CISC (Complex Instruction Set Computer)
- Összetettebb (komplex) utasításkészlettel rendelkezik
- RISC-nél nagyságrendekkel több utasítással bír
- Utasítás végrehajtása viszonylag lassú, de kevesebbre is van belőlük szükség az adott feladat elvégzéséhez.

Ha a fenti dolognál maradunk, csinálhatnának rendes CISC vagy RISC processzort is... ugye a visszafelé kompatibilitás a legtöbb jelentkező probléma (korlát) okozója.

Persze sok egyéb különbség van közöttük...

A CISC-RISC dolog talán kicsit hitvita is, önmagában egyik vagy másik alkalmazása nem feltétlenül jelent előnyt.
No meg gondolkodhatunk mikrovezérlőkben is, közöttük is megfordul mindkettő, nem feltétlenül csak PC-architektúrából lehet kiindulni...

...szóval azért azt, hogy a CISC architektúra "hülyeség", egy kicsit bátor dolog kijelenteni...

Az, hogy milyen eszközt használ az ember attól is függhet, hogy milyen célra szeretné használni... persze PC esetén általános célú processzorról van szó...

Szerencsére Linux sokféle gépen elfut, így túl nagy gondot egyelőre ez nem okozhat... :)
Apple építkezett sokáig RISC processzorra (pl. PowerPC), de pl. a routeremben is az van.

Épp itt írtad le. CISC-s utasítások lényegesen bonyolultabbak. Alapvetően azt vették figyelembe, hogy könnyen kódolható legyen. Csakhogy amióta nem ASM-ben írunk minden vackot, hanem C-ben, C++-ban, újabban Java-ban, .NET-ben, mindenféle script nyelveken, és egy fordítóprogram állítja elő a kész gépi kódot, azóta sok értelme nincs annak, hogy viszonylag könnyen olvasható.

Ezzel szemben lényegesen bonyolultabb felépítésű processzort igényel, amit egyrészt drágább, nehezebb fejleszteni, másrészt drágább is a bonyolultabb felépítés miatt és összességében sokszor lassabb megoldást eredményezett. Ezen röhögtem anno, hogy az AMD gyk. 3-4 évig nem emelt órajelet lényegében (legyen mondjuk 1800 Mhz környékén, kezdve a K7-s Athlonoktól a mindenféle K8-s procikig) mégis gyorsultak a processzorok. (AMD K6 óta RISC) Ezzel szemben az Intel ott szenvedett, hogy hova emelje a P4-eseinek órajelét, hogy tudja tartani a lépést az AMD-vel. Aztán persze rájött, hogy nem fog menni, dobták is az egész netburst-s szutykot és leporolták a P1-P2 közötti PentiumPro mellékvágányt, és lett belőle egy szintén RISC-re bontó Core mikroarchitektúránk. Lehet feltűnt, de teljesítményben, fogyasztásban proba alázza a régi P4-s vonalat.

Komplexebb dolgokkal mindig csak a baj van az informatikában: nehezen optimalizálható. (IA64-re is sok helyről azt hallottam, hogy szép meg jó meg minden, csak épp annyira bonyolult, hogy nehéz rá jó fordítót írni).

----------------
Lvl86 Troll

Azért keveritek itt a dolgokat picit.

Egy mai x86 processzor (Pentium Pro-tól, K7-től kezdve) A Cisc utasításokat rögtön a feldolgozás elején felbontja elemi, egyszerű utasításokra. Sőt a poén az, hogy egy modern Risc processzor is ezt teszi. (PowerPC 604-től)
Innentől kezdve a processzorok felépítése nagyvonalakban megegyezik, a funkciók ugyanazok, csak más-más trükkökkel operálnak a gyártók, illetve egyre több a végrehajtóegység, meg a cache.

Tehát a lényegi különbség a Cisc és a Risc között az, hogy a Cisc-nek a kezdeti dekódoló lépése bonyolultabb. Emiatt pár lépéssel hosszabb a pipeline. (x86: 8 lépés, PowerPC: 3-4)

A NetBurst (Pentium 4) architektúra meg azért lett rossz, mert durván megnövelték a pipeline-t. Amd k7-k8, Core 1-2, PowerPC G4-5: 20-25 lépés. NetBurst: 39. Tették ezt azért, mert hosszabb pipeline --> egyszerűbb lépések --> nagyobb órajel. Terveik szerint a NetBurst 10 GHz-ig skálázódott volna. Ez a sebesség már ellensúlyozta volna a hosszú pipeline hátrányát, csak ezt a sebességet sosem érték el.

További adat, hogy az x86 processzor bonyolultabb dekódoló része a mag 5%-át foglalta el 3-4 éve. Ez mára még kevesebb. Tehát ez sem számottevő hátrány.

El lehet már felejteni ezt a régi Risc vs Cisc vitát, mert már teljesen értelmetlen. Apple váltott, és... nem történt semmi. Az új gépek gyorsabbak mint a régiek...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

Az arm9-et kicsit tul haladta mar technika, azota 16 regiszter a meno. PPC32-n 32 van. Plusz a RISC javara irhato, h a spec szerint minden utasitasnak illik egy ciklus alatt vegrehajtodnia, tobbek kozott emiatt szerepel a G4 SIMD muveletekben fenyesebben, mint x86-os tarsai. Lenyeg, h azert van ott meg par kulonbseg a ket arch kozott.

---
pontscho / fresh!mindworkz

Az arm9-et kicsit tul haladta mar technika, azota 16 regiszter a meno.

arm9-ben is 16 regiszter van (marmint amit lat az applikacio). mikepp az x86_64-ben. most megneztem, az arm cortex A8-ban is (ez igazan modern cucc es riscnek mondjak).

Plusz a RISC javara irhato, h a spec szerint minden utasitasnak illik egy ciklus alatt vegrehajtodnia, tobbek kozott emiatt szerepel a G4 SIMD muveletekben fenyesebben, mint x86-os tarsai.

ez x86-on is igy van mar egy ideje, sot egy orajel alatt tobb utasitast is vegrehajt (szuperskalar), simd-t is. ellenben pl. ultrasparc III-on (nem a legujabb, de ezt hasznaltam) pl. egy szorzas kb. 5 orajel, tehat nem egy (es kozben amugy megall az egesz pipeline, hehe).

Lenyeg, h azert van ott meg par kulonbseg a ket arch kozott.

van, csak nem lenyegesek ( [szerk]es azaz[/szerk] nem nagyobbak mint ami ket risc (vagy ket cisc) proci kozott is van).
szerk2: szoval oke, ha az egyik proci egy utasitassal megoldja az univerzum egyenletet (es mindezt mikrokodbol), a masik meg csak osszeadni es kivonni tud de azt hardverbol, akkor az elso cisc a masik meg risc nyilvan, de en csak azt mondtam (amivel te ha jol ertem vitaba szalltal), hogy a gyakorlatban altalaban (es konkretan x86_64 eseten) nincs ilyen eles kulonbseg. na mindegy a cisc vs. risc kerdesnek ugy latom eleg nagy irodalma van a neten, en csak egy velemenyt (a sajatomat) irtam le.

- Use the Source Luke ! -

szoval oke, ha az egyik proci egy utasitassal megoldja az univerzum egyenletet (es mindezt mikrokodbol), a masik meg csak osszeadni es kivonni tud de azt hardverbol, akkor az elso cisc a masik meg risc nyilvan, de en csak azt mondtam (amivel te ha jol ertem vitaba szalltal), hogy a gyakorlatban altalaban (es konkretan x86_64 eseten) nincs ilyen eles kulonbseg

Ebben. Viszont egy aprosag van. Ha mikrokodban letarolod a The Big Bang Theory-t, azzal ket negativ kovetkezmenyt is bevonsz a jatekba: novekszik a CPU komplexitasa (ezzel a kihozatal aranyosan csokken, a fogyasztas no, satobbi), valamint ha kozben rajonnek, h megsem volt Nagy Bumm, hanem mondjuk a Nagy Keresztespok szotte az univerzum szovetet, akkor a vasat lehet roptetni. Ezzel szemben ha csak osszeadni es kivonni tud, de azt mocskos gyorsan, akkor eleg csak a szoftvert modositani. Erre eleg jo bar sarkos pelda volt a DNETC, ahol romma alatza az AltiVec-re optimalizalt klienssel a PPC a kortarsait.

---
pontscho / fresh!mindworkz

Az erősen kérdéses, hogy a regiszterszám manapság mennyire számít.
Egy PowerPC 970-nek 32 általános regisztere és 48 rename regisztere van (belső regiszter a nem valós függőségek kiküszöbölésére).
Egy P4-ben ugyanez a két szám 8 és 120.

Nyilván az AMD megtehette volna, hogy nem 16-ra növeli az x86-64-ben hanem többre, de mégse tette. Ezek nem hasraütésszerű döntések, tehát vélhetően nem nagyon számít...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

Ha azt nezzuk, h az x86 8 "altalanos" regisztere kozul csak 4 "valoban" az, eleg sokat szamit az a +8 regiszter, valamint, h az altalanossag fogalmat kiljebb terjesztettek. Pont emiatt az alacsony regiszterszam miatt alakult ki az, h stack-en csomo mindent tarol, mig ez RISC eseten a regiszterekre tamaszkodik. Persze, a L1 cache-ek ota ez nem olyan egetrengeto dolog, de ha azt nezed, h ezt szinkronizalni kell a memoriaval, valamint a teljesitmenye meg mindig alacsonyabb a regiszterekhez kepest, okoz nemi teljesitmeny veszteseget. ARMv6-on (es ugy altalaban a RISC architekturakon) speciel az r0-r3 regiszterek szolgalnak parameteratadasra es csak akkor foglalkozik memoriaban torteno parameteratadassal ha ennel tobb argumentumra van szukseg, es egyeb regiszter alapu optimalizaciora is lehetoseget ad amit a compilerek erosen ki is hasznalnak. Ez alacsony regiszterszam mellett kenyszerit a memoria hasznalatra. Azert lassuk be ezzel eleg sok memoria/cache muveletet meg tud sporolni. Az h ez x86 eseten (bocsi, m68k kimaradt az eletembol) a stack lett szokas/mervado koszonheto az alacsony regiszterszamnak is az elcseszett architektura mellett.

---
pontscho / fresh!mindworkz

Volt idő, amikor teljesen igaz volt, amit írsz... a risc jobb volt, gyorsabb, stb. Kb. 80-as évek végén, 90-es évek elején.

De mostanában a cisc-ek is gyorsan hajtják végre az utasításokat.

Viszont... mivel kevesebb utasítás van a cisc procinak ugyanahoz a feladathoz, elég kisebb cache. A cache hit pedig fontos dolog, mert lehet akármilyen gyors a proci, de ha memóriából kell behúznia az utasításokat, belassul keményen.

G

Ezt szerintem bőven ellensúlyozza az, hogy RISC-en rövidebb a decode, és hamarabb elindulhat a branch prediction...

Egyébként sem hiszem, hogy a fő problémát az utasításcache okozná, ha így lenne, már rég megduplázták volna...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

Ezt szerintem bőven ellensúlyozza az, hogy RISC-en rövidebb a decode, és hamarabb elindulhat a branch prediction...

Egyebkent az intel doksi 14 staget ir a core 2 pipeline hosszara, az ibm meg legalabb 16-ot a ppc 970FX-re (tudom ez regi, nem tudom hol van ujabb es bikabb ppower - pl power6 - procirol doksi).
Nem ellenoriztem (ugye nem tudom szetszedni a procit es megnezni), de erdekes adat.

- Use the Source Luke ! -

Amikor az erről szóló hozzászólást írtam, utánanéztem az adatoknak, és kiderült számomra, hogy a pipeline hosszába a decode részt gyakran nem számolják bele. Így lesznek ezek 20 alatt.
És így lesz a PowerPC esetleg hosszabb.

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

Többnyire látszik az ábrákon, illetve kiderül a szövegből, hogy a decode részt nem számolják hozzá. Nomeg az is gyanús, ha az egyik leírás 16-os a másik 24-es pipeline-t ír ugyanarra a procira...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

hat melyik doksi, melyik abra, mert en nem talalom? Te is a core mikroarchitekturarol beszelsz? mindenesetre meg akarom merni ha otthon leszek.

szerk: argh, ja, hogy a ppc-re irnak 16-ot az egyik helyen 24-et a masikon. mindegy a core 2-t megprobalom majd megmerni, es ide megirom, biztos mindenkit erdekel!

- Use the Source Luke ! -

( enpassant v | 2009. 03. 17., k – 18:44 )

Én úgy tudom, hogy az AMD a Global Foundries-zal csak gyártatja a processzorait, a licenceket nem adja át neki. Innentől értelmetlen a vita.

( tr3w v | 2009. 03. 18., sze – 13:28 )

Ez csak a szokásos kardcsörtetés. Egymástól licenszelik a technológiákat, így egy összeveszésen mindketten csak vesztenének.

Az Intel csak megpróbál betenni az AMD-nek, mert nyilván nem tetszik neki, hogy hirtelen pénz állt a házhoz, plusz addig sem a trösztellenes eljárásról beszél a sajtó...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o