https://www.tomshardware.com/pc-components/cpus/intel-terminates-x86s-i…
Akinek kimaradt volna, az x86S az Intel kezdeményezése volt 2023 májusában, hogy egy bloat-mentes, csakis 64 bites x86 architektúrát hozzanak létre. Na most beismerték, hogy ez befuccsolt. Ráadásul nem is akarnak a továbbiakban semmilyen x86-os irányvonalat meghatározni, helyette létrehozták az "x86 Ecosystem Advisory Group" csoportot (ami legalább annyira lesz képes de-bloatolni az x86-ot, mint a W3C a HTML-t (szarkazmus)).
Szóval a lényeg, hogy
1. nem lesz karcsúsított x86, marad a visszafelé kompatíbilis verzió
2. nem az Intel mérnökei fognak dirigálni már
3. kutyaütők kezébe került a szakma (az Intel-en és AMD-n kívül a Gúgli is bele fog ugatni, már persze ha nem daraboltatja fel a kongresszus)
(ui.: azt csak halkan jegyzem meg, hogy az Intel mindent megtett eddig, hogy eltitkolja, amióta van 64-bites x86, azóta már nem az ő kezükben van a gyeplő, hanem az AMD-ében, és az Intel vaskos borítékokat fizetett eddig is az AMD64 licenszdíjaíért, amit x86_64-nek brandelt. A különbség e kettő között minimális, többnyire a cpuid utasításra és néhány modell specifikus regiszterre szorítkozik. Most tehát csak annyi történt, hogy beismerték, veszítettek és az AMD hivatalosan is az irányvonalat adó csoport tagja lett.)
Hozzászólások
Elvileg már le is járt a szabadalmak egy része az ősi x86-ról, csak a folt-hátán-folt megoldás miatt folyamatosan bővült valamivel, amire külön szabadalom vonatkozik, így legfeljebb akkor lehet bárk által felhasználható és kompatibilis, ha már lekapcsolták a villanyt és évtizedekig nem változik semmi.
Azt nem tudom, hogy felszabadult -e már annyi az utasításkészletekből és megoldásokból, hogy valaki retro célból szabadon gyárthasson régi procikkal kompatibilis soc-ot. Elvileg már az x86_64 is felszabadult az sse2-ig. Manapság is árulnak olyan procira épülő ipari soc-ot, ami x86 és még pcie is van rajta, az is valami legacy utasításkészletre épül és nem sokat változik. Néha felkapják retro minipécé szériákhoz, amúgy meg éttermi konyhai kijekzőben és hasonló helyeken fordul elő.
Azt hiszem ebben elég jól összefoglalták, DM&P Vortex86
https://www.youtube.com/watch?v=BdSJgoP2a88
Ez meg egy aktuális retro mini pc
https://www.youtube.com/watch?v=B8WfiRRvQXo
ME azért legyen benne, pont a SMM és a SGX mellett. És Microsoft Pluton.
Én olvastam a spec-et, amikor megjelent; tetszett a tartalma [*], de azért várható volt, hogy ugyanarra a sorsra fog jutni, mint az Itanium, részben ugyanazért (= az inkompatibilitás miatt).
(Nem pontosan ugyanazért -- az Itanium-nál több ok is volt a bukásra tudtommal, nem csak a inkompatibilitás. Nagyon drága volt, és nem sikerült olyan compiler-eket készíteni, amelyek az Itanium utasításkészletét ill. utasítás-csoportosítását ki tudták volna használni.)
[*] Minden kernel- / hypervisor- / firmware-szintű kódban továbbra is szüntelen hajtépés a CPU módok váltása (real mode-ból eljutni long mode-ba). Nem könnyű sem debug-olni, sem (pl.) virtualizálni.
Igen, olyasmi. Bár az x86S jobb esélyekkel indult, de benézte az Intel azt, hogy mivel járna átállni rá (itt nem fordítókra gondolok, hanem hogy mennyire bele van vasalva a real mode - prot mode - long mode az alacsonyabb rétegekbe, BIOS ROM-ok, APIC inicializiáció, stb.) Az meg, hogy bukott volna vele a 32-bites library és app támogatás (legacy mode) hab a tortán, a Microsoft biztos fúrta miatta. Valószínűleg a RedHat / Oracle / stb. sem lelkesedett az ötletért, bár Linux alatt könnyebb kibekkelni, ha nincs lib32.
Az Itanium egyébként durva cucc volt, mert nyilvánosan konfigurálható volt az ISA-ja. Ha valaki akarta, akkor mondjuk az egyik core-ból csinálhatott M68K-t. Érdekesség, hogy ez a technológia továbbra is megvan x86-on, de már nem nyilvános, és csak arra használják, hogy az x86-os ISA-t toldozzák-foltozzák vele (microcode update). Pedig lehetne más ISA-t is betöltetni vele akár, mint az Ithaniumon. RISC-en szoftveresen emulált CISC az x86, furcsa egy jószág, na, lenne mit karcsúsítani rajta.
Mindettől függetlenül szerintem lett volna létjogosultsága az x96S-nek egy bizonyos rétegben, kb. mint az Intel Atom-nak. Egy ratyi, sose lett mainstream, de ha x86-os programokat kell futtatni olyan környezetben, ahol nagyon fontos az alacsony fogyasztás, arra kifejezetten jó (mondjuk másra nem). Hasonlóan egy csak 64 bites x86-nak is lett volna helye, szvsz.
Hát nem triviális, az biztos. Ráadásul a mai modern fordítók nem is kezelik már helyesen. Például itt egy durva hákolással tudtam csak megoldani, hogy a fordító olyan prot mode utasítást fordítson, amit majd futás közben helyesen real mode-ban hajt végre a CPU... Egyszerűen nem lehetett olyan valós módú utasítást megadni, ami a módváltáshoz szükséges, mert már nem tudja azt a fordító inline assemblere...
Lehet, hogy az Atomnak volt anno létjogosultsága, de az ARM mgmutatta, hogy kis fogyasztással is lehet teljesítményt produkálni.
Igen, de az ARM nem tud x86-os programokat futtatni, az Atom meg igen. Persze ha megvan a forrás és lefordítható, akkor nem vitás, ARM a nyerő.
Az Apple meg tudta oldani, mikor az M1-es procira váltott. Legalábbis a többségét képes volt futtatni.
hat azert azt ugy csinaltak, hogy raktak egy csomo plusz utasitast a procijukba direkt az x86 emulaciohoz, es arra forditja at a kodot.
egy tisztan ARM utasitaskeszletu procin az ugy nem mukodne, persze lehet arra is forditani/emulalni, qemu is megoldja, de nem lesz olyan gyors
Kiváncsi lennék, hogy hogy működik ez? Van valami cikk, ami összefoglalja "pár mondatban". Ha elképzelem, hogy hogy csinálnám, akkor az utasításokat átfordítani még sima ügy lenne, de utána jön, hogy az ugrásoknak fix címe van, és az átfordított programban a címek mind máshová esnek. Ezt hogy oldják meg?
igen van rola egy jo hosszu tech cikk, a hupon linkelte valaki egyszer... engem is az ugrasok izgattak, de az asszem pont nem derult ki belole.
https://dougallj.wordpress.com/2022/11/09/why-is-rosetta-2-fast/
Köszi!
Egyszerűen újraszámolják. Pontosan úgy, mint bármelyik JIT compiler, csak itt fiktív bytecode helyett x86-os kódolást használnak bemenetnek.
Egyébként a qemu-ra pont nem jellemző ez a fajta emulálás, az szoftveresen értelmezi az utasításokat, egyesével, libasorban, így nem is kell újraszámolnia. Cserébe lassú, mint a fene (mármint x86 guest ARM host esetén).
(Az asztali gépeden a qemu azért olyan gyors, mert a guest is és a host is x86, natívan futtat szinten minden utasítást (kivéve a trapeket). De ehhez az kell, hogy a guest és host architektúrája egyezzen, és a kernel engedje futtathatónak belapozni a guest memóriáját. Ha eltér az architektúra, vagy a kernel nem támogatja a belapozást, akkor a qemu is tetves lassú lesz, ezt kipróbálhatod, ha "-no-kvm" kapcsolóval indítod.)
"...raktak egy csomo plusz utasitast a procijukba direkt az x86 emulaciohoz, es arra forditja at a kodot."
Oké, de ez nem ördögtől való, ha a szent kompatibilitás oltárán kell áldozni :-) Az Apple egyébként már korábban is váltott platformot, és nem mindig volt olyan jófej, hogy támogatta az átállást. Ha jól emlékszem, a PowerPC-Intel átálláskor nem erőlködtek ennyire, hanem csak közölték a nagyközönséggel, hogy vegyék meg a szoftvereket Intel platformra is.
> PowerPC-Intel átálláskor
de, mar volt akkor is Rosetta (azret hivjak a mostanit Rosetta 2-nek), ami tudta futtatni a powerpc kodot intelen. mondjuk nem volt gyors :)
sot mar elotte is volt valami emulator ami powerpc-n emulalt talan pentium procit, igy egyszerubb pc appok futottak rajta.
Ami erre jól használható megoldásnak tűnt (az edk2-ben), az az volt, hogy az ilyen kódrészleteket NASM forrásban írtunk meg; ott a BITS direktívával szabadon lehetett váltogatni, hogy milyen módra fordítsa a direktívát követő utasításokat. Többféle módon is használtuk (emlékezetből írom, úgyhogy a felét se hidd el :) )
A NASM egy nagyon jó eszköz.
Ezt a gcc / Clang is tudja, a ".codeX" direktívával. A gond az, hogy nincs minden utasításra felkészítve, mert az átlag programozónak úgysem kell, a döntő többség úgysem használ kevert módot.
Régen használtam NASM-ot, de nem szerettem, mert nekem túl bloated és lassú. Átváltottam flatassembler-re, milliószorta jobb, nagyon meg vagyok elégedve vele. Kissebb, gyorsabb, és a makrónyelve fényéveket ver a NASM-ra. Ráadásul van belőle fasmarm cross-compiler is. Ebben a projektemben például úgy generálok BIOS Option ROM-ot, hogy flatassembler makrókkal számíttatom ki az ellenőrzőösszeget menet közben, ilyent a NASM nem tud.
OFF: Igazából azt nem értem, hogy az ARM architektúrára miért nem feküdtek rá jobban. Mostanában jelentek meg az első ARM procis nem-Apple gépek, és a rájuk elérhető szofrverkörnyezet is elég karcsú A Microsoft érdekes módon ott van ezen is, és hallottam egy Linux disztróról, de csak ennyi... ez nekem valahogy elég vékonyka.
Pedig az Apple megmutatta, hogy ARM architektúrán mi mindent lehet, és meglepő módon ezt pozitív értelemben tette :-)
Az Intel nekem úgy tűnik, jó 3-4 év lemaradásban van. Még azt sem feltételezem, hogy a j átékipar nyomására nem erőlködnek, hiszen egy új platform többnyire azt jelenti, hogy ugyanazt a szoftvert el lehet még egyszer adni...
pedig 20 eve meg volt az intelnek igen jo arm procija, amit akkoriban a dragabb pda-kba raktak.
Igen, nekem is volt Siemens Pocket PC-m, ezért csodálkozom, hogy az Intelnél miért halt el ez a vonal.
Ennek szerintem nem technikai, sokkal inkább jogi és balfasz vezetői döntés az oka.
ARM-ot egyébként nem is olyan egyszerű licenszelni, és még akikkel szerződést is kötöttek, megy velük a jogi csatározás (ld. Qualcomm esete).
Nem véletlen, hogy a kínaiak, akik egyébként hírhedten magasról szarnak a szerzői jogokra, na még ők is inkább saját Loongson architektúrával próbálkoztak helyette. Most meg már ott van a RISC-V, mindenki, aki nem akar szarakodni az ARM Ltd.-vel, arra kezd átállni inkább ARM helyett. Még gyerekcipőben jár, de érezhetően jön fel.
Az ARM-ot egyáltalán nem nehéz licenszelni.
Egyrészt ha kész processzormagot veszel tőlük, amit egy az egyben beépítesz a saját SoC-dbe, akkor van "core license" ami elég világos konstrukció. A fél világ így veszi, jogi problémák nélkül.
Van aztán olyan, hogy kész magot veszel, de belemódosíthatsz és ehhez az ARM teljes engineering supportot is ad. Ez a "Built-on ARM" licensz. Ezt is jópár cég csinálja. A Qualcommnak is ilyen licensze van.
És van az "Architecture license" amikor teljesen magad tervezel processzormagot ami ARM ISA kompatibilis. Ezt viszonylag kevesen csinálják. Pl: Apple, Ampere, Amazon.
Érdekes módon az Amazon ugyanúgy jutott hozzá saját fejlesztésű ARM magokhoz (ez az amit "Graviton" márkanéven találsz AWS-ben), mint a Qualcomm: felvásároltak egy-egy startupot. De az Amazon esetén valahogy nem volt semmi jogi probléma belőle.
Nyilván az ARM startup cégeknek óriási kedvezményeket adott, hogy a belépési küszöb alacsony legyen. Viszont tudják, hogy mi az exit-stratégia, ezért kikötötték, hogy a "kedvezményes" licensz nem száll át másik cégre felvásárlás esetén. Pontosan azért, hogy ne lehessen úgy kijátszani, hogy egy nagy mammutcég, egy kis startup közbeiktatásával szerezzen "jóárasított" ARM licenszet. A Qualcomm pont ezt próbálta csinálni, és úgy tűnik sikerül is bírósággal kimondatniuk, hogy az ARM szerződésében a felvásárlásra vonatkozó korlátozás nem törvényes.
Szóval ehhez a jogi "csatározáshoz" azért két fél kellett. Van párszáz másik cég, ami évtizedek óta surlódásmentes jogi kapcsolatban van az ARM-mal.
Régóta vágyok én, az androidok mezonkincsére már!
Én úgy tudom, hogy kész processzort egyáltalán nem is vehetsz tőlük, mert az ARM nem gyárt ilyent. Ők csak a tervrajzot licenszelik, neked kell legyártanod. A honlapjukon is ezt írják, hogy "In short, Arm licenses the instruction sets for modern chips to partners, who then make chips with customizations for their unique applications.", tehát ők nem gyártanak hardvert, csak a partnereik.
Ennek se füle, se farka. Csak magot egyébként sem lehetne venni, még akkor sem, ha történetesen gyártanának hardvert ARMék. Megint max. licenszről lehet csak szó.
Vitathatatlan. De ettől a tény még tény marad, hogy jogi csatározás esete forog fenn az ARM és legnagyobb gyártója között. RISC-V esetén nincs és nem is lehet ilyen probléma, azért kezdenek egyre többen átváltani arra.
ps: bakker, megpróbáltam arra keresni, hogy hol gyártanak ilyen csipeket, de képtelenség, mert hát ugye "arm" fegyvert jelent, így pisztolygyárakat dobált ki a kereső...
Ezt írtam: "egy az egyben beépítesz a saját SoC-dbe" - hogyha egyszer tudod, hogy mi a helyzet, akkor miért gondolod, hogy én úgy értelmezem, hogy fizikai legyártott formájában veszi meg az ARM-tól? SoC = System on a Chip, nyilván csak IP blokként tudja megvenni, nem fizikai IC-ként, különben hogy tenné bele az SoC-be az ARM magot?! :)
A "Core license", mint neve is mutatja, valóban egy licensz vásárlása, nem pedig egy fizikai magé, el nem tudom képzelni, hogy olvastad ki ez utóbbit a hozzászólásomból.
"Ennek se füle, se farka." - akkor lehet, hogy mégsem érted. Az ARM-tól vehetsz (nyilván licensz konstrukcióban, nem fizikailag) egy komplett mag design-t, mint IP blokkot többféle formában. Veheted adott gyártástechnológiára teljesen előkészítve (gyakorlatilag a maszkokat megkapod, mondjuk TSMC N8 process-re, amit egyben copy-paste-elsz a saját IC-d maszkjába. Ez a legegyszerűbb és legkevésbé kockázatos, teljesen ki van tesztelve előre.) Veheted ugyanezt a processzormagot valamilyen HDL nyelvű leírásként, amiből viszont neked kell egy konkrét gyártástechnológiára layoutot szintetizálni, ehhez az ARM ad tech supportot. Ez akkor kell, ha olyan foundryval akarsz gyártatni, amire az ARM-nak nincsenek kész maszkjai (ez nyilván macerásabb, finomhangolni kell, mire használható kihozatalod lesz). Itt még mindig logikailag kapu szinten pontosan azt gyártod, amit az ARM tervezett. Ez az ún "core license".
Amikor már valamit módositasz a HDL leíráson (cache mérete, végrehajtóegységek száma, egyes utásításkészlet kiegészítések ki-be rakása), akkor van a "Built-on ARM" licenszkonstrukció. Itt még mindig az ARM-tól kapott HDL leírással dolgozol, de bizonyos dolgokat átparaméterezhetsz benne. De nem 0-ról tervezed át az egészet.
És van az a konstrukció, amikor teljesen te csinálod az egész processzor HDL leírását, az ARM lényegében csak a jogot adja el és a megfelelőségi teszteket.
"De ettől a tény még tény marad, hogy jogi csatározás esete forog fenn az ARM és legnagyobb gyártója között" - najó, de mégegyszer, van 100+ cég, akinél valahogy nem volt jogi csatározás. Megkötötték a szerződést, betartották ami benne volt, és nem volt per.
A Qualcomm egyszerűen ki akarta játszani a licenszfeltételeket azzal, hogy a Nuvia felvásárlásán keresztül jusson jóárasított Architecture License-hez. Először ráadásul sunnyogtak, mert megpróbálták elsütni a "Built-on-ARM" licensz keretében a Nuvia-tól vett teljesen custom processzormag design-t, csak lebuktak azzal, hogy a Nuvia még a felvásárlás előtt egy az egyben ugyanezt beküldte conformance tesztelésre az ARM-hoz "Architecture license" programon keresztül. Aztán jöttek azzal, hogy az ARM szerződéses korlátozása (a kedvezményes architecture license nem vihető át a cégek között) érvénytelen, mert az egész (Nuvia) céget megvették, ezzel minden jogi asset is átszállt a Qualcommra és törvény-szerint ez nem korlátozható. Egyelőre úgy tűnik, hogy a bíróság a Qualcommnak fog igazat adni, de amennyire tudom ez még nem lefutott meccs.
Régóta vágyok én, az androidok mezonkincsére már!
Ez a Qualcomm-os dolog is azt mutatja, hogy ez a licences dolog kicsit risky, mert ha az ARM-nek nem ugyanaz a jog- vagy szerződésértelmezése, akkor meg is vonhatja a licenchasználatot, te meg nézhetsz a lukon. Valahol megértem, hogy kicsit rossz precedenst teremtett ez, és keresik a kevésbé problémás megoldást.
Az, hogy 100+ cégnél - még - nem volt jogi csatározás, az valójában semmit nem jelent. Vagy az ARM számára még nem buktak ki a shady lépések, vagy annyira kicsi az adott cégek piaca, hogy nem akartak/nem érte meg nagyon belenyúlni nekik.
Blog | @hron84
via @snq-
Lásd lentebb, amit írtam. Reálisan ma már nem tudod kikerülni az IP blokk licenszelést. Annyira bonyolult és drága lett 0-ról implementálni (majd validálni) bármilyen korszerű memória/perifériabusz szabványt, hogy mindenki licenszeli ezeket. A legnagyobbak is. Az ARM processzor csak egy tétel a listában. Lehet hogy a legdrágább tétel, kivéve ha GPU vagy újabban NPU is képbe kerül, mert akkor azok lesznek a legdrágábbak. Bármelyik ilyen IP-blokk szállítóval lehet jogi probléma. Arra mindenképpen lehet számítani, hogyha a kliens nem óhajtja betartani az IP blokk vendor szerződéses feltételeit, akkor az meg fogja próbálni érvényesíteni bíróságon.
Régóta vágyok én, az androidok mezonkincsére már!
"RISC-V esetén nincs és nem is lehet ilyen probléma, azért kezdenek egyre többen átváltani arra."
Erről még annyit, hogy elméletben igazad van, csak gyakorlatban nem. A kérdéses ARM Architecture License akkor jön képbe, ha valakinek nem elég a legerősebb processzormag (Cortex X széria, ill. Neoverse V széria) amit az ARM komplett design-ként adni tud. Jelenleg a RISC-V ebben a ligában nem is játszik. Kb az ARM little (Cortex A5) és még kisebb (A3, M) magjaival tud versenyezni. Big core-ban legfeljebb a 8-9 évvel ezelőtti (A73, esetleg A75) modellekkel. Akinek viszont megfelel a konfekciómodell, annak óriási előny, hogy készre tervezett processzormagot (adott gyártástechnológiára összetesztelve, előre ismert várható selejtszázalékkal, előre ismert órajellel, fogyasztással) kap az ARM-tól.
A RISC-V-nél vagy magad nekiállsz HDL-ből szintetizálni, vagy ... wait for it ... licenszeled egy olyan cégtől aki abban utazik, hogy készre tervez RISC-V magokat. És akkor még mindig egy csupasz processzormagod van, kell még memóriavezérlő, kellenek perifériák, buszvezérlők, GPU stb. Ezeket megintcsak nem rakod össze 0-ról, mert egy LPDDR4 vagy 5 memóriavezérlő tervezése, kitesztelése és megfelelőségi tanúsítása önmagában alsó hangon sok-sok tízmillió dollár és több év (mire elkészülsz el is avul). Egy PCIe 5.0 vagy USB3/4 vezérlő ugyancsak. Még az AMD sem áll neki maga fejleszteni ezeket, ők is licenszelik 3-ik féltől.
Szóval a processzormag csak egy tétel a sok közül. Vannak cégek akik beágyazott rendszerben (pl Western Digital a merevlemez vezérlőiben) bevállalta a RISC-V-vel járó kockázatot (pun intended), hogy szabaduljon az ARM-től. Meg vannak főleg kínai cégek, akik politikai okokból akarnak szabadulni az ARM függőségtől, nehogy a nyugati vezetők tényleg "fegyvernek" használják.
Régóta vágyok én, az androidok mezonkincsére már!
A Loongson lényégében egy licenszeletlen (ezért Kínán kívül eladhatatlan) MIPS architektúra. Nyilván elforkolták, és elkezdtek módosításokat beletenni, de alapvetően "nem saját".
Régóta vágyok én, az androidok mezonkincsére már!
A Wikipedia azt írja és linkeli, hogy a Loongson nyert 2024-ben a MIPS-szel szemben, ergo jogszerűen használja az architektúrát.
Nagy változás majd a RISC-V lesz, jelenleg még gyengusz, kísérleti fázisú, nem versenyképes, de ha felnő, akkor megszűnik ezzel a llicencekkel szórakozás.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Én úgy tudom hogy az IBM open source licensz alatt kiadta a Power 9 ISA-t. Ez volt?/van az OpenPower kezdeményezés.
https://newsroom.ibm.com/2019-08-21-IBM-Demonstrates-Commitment-to-Open…
https://openpowerfoundation.org/
Továbbáa MIPS is kiadott ISA-t open source alapokon OpenMips néven ha jól? tévedek. Aztán mégsem? erre elég kevés infó van.
Aztán még 2005? -ben a SUN (Oracle?) az OpenSparc kezdeményezéssel kiadta a T2 kódját.
https://www.oracle.com/servers/technologies/opensparc-t2-page.html
Ezek a kezdeményezések aztán teljesen elhaltak valamilyen (jogi?) okból...
Lehet egyébként az x86S nem lett volna rossz ötlet. Az Intel ott számította el magát, hogy most nem ők diktálnak, jelenleg ők az underdog. Lehet nem is lesz szükség az x86S-re, ha az ARM ilyen léptékben fejlődik, és PC fronton a bootloaderét szabványosítják. Nem tudni hová tartanak a trendek, főleg most, mikor félévenként hoz ki mindenki mindenfélét, pár napja a Nvidia jelentett be egy új ARM workstationt, amit idén fognak kihozni.
Az Intel meg nem fizet semmilyen licencdíjat az AMD-nek az x86_64-ért, hanem peren kívül megegyeztek, hogy egymás szabadalmait keresztbe licencelik, tehát az Intel ingyen gyárthat AMD64 utasításkészletes procit, de cserében az AMD használhat bizonyos Intel szabadalmakat.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Én finance-ban dolgozom, ami szuper konzervatív. De már itt is az AMD pörög szerver oldalon. 5 éve ez sci-fi lett volna.
https://naszta.hu
Igen, lényegében ezt ismerték most be azzal, hogy elkaszálták a próbálkozást és létrehozták helyette ezt a csoportot.
Nem hiszem. A pontos részletek nem nyilvánosak, így nem tudhatjuk; de amíg az Intelnek esélye sincs 64-bites procit csinálni az AMD nélkül, addig az AMD nemigen van rászorítva egyetlen Intel szabadalomra sem, szóval nem hiszem, hogy fizetés nélkül csak úgy bartelbe menne a dolog. De csak tipp, a megállapodás részleteit nem ismerjük.
Most nincs rászorulva az AMD az Intel szabadalmakra, de ne feledd, hogy ez nem mindig volt így. Egészen a Bulldozer, Piledrver, stb. generációig, az Ax és FX-ekkel bezárólag durván küszködtek, és akkor számított, hogy HTT-nek, AVX, VT-x-nek megfelelő megoldást szállíthattak, mert az Intel szabadalom hiába nevezed át SMT-nek, meg akárminek, beperelhetnek érte. Ez a megegyezés nyilvános a két cég között, valóban a részletei titkokban vannak tartva, de ennyit biztosan tudni, hogy az Intel is ezért használhatja az AMD64 utasításkészletet, és ezért nem pereli be érte az AMD, megegyezés van közöttük. Az Intel 64 bitnél nem az x86-at vonalat vitte tovább, hanem az IA64/Itanium vonalat, azzal is beégtek elég csúnyán, mire meg összekapták magukat, az AMD beelőzte őket.
“The world runs on Excel spreadsheets.” (Dylan Beattie)