Myslím že hej... tu je biela kniha na stránke Intelu: https://www.intel.com/content/www/u...visioning-future-simplified-architecture.html
Takže... zbaviť sa všetkého starého cruftu a spustiť iba x86-64. Myslím, že by to malo zjednodušiť veľa logiky. Menej sily? optimalizovaná logika (beží rýchlejšie)? menšia plocha matrice? Je zrejmé, že veľa ľudí bude proti tomu len preto.
Zaujímalo by ma, koľko 32-bitového kódu spustím v danom roku; dá sa to nejako sledovať?
Neprivilegovaný kód však stále môže byť spustený s väčšinou natívnym výkonom; tento návrh je len o znížení podpory na úrovni OS.
Opäť - väčšinou sa týka aplikácií, nie operačných systémov. Čokoľvek moderné by potrebovalo stabilnú cestu na spustenie priamo do 64-bitovej verzie, pretože všetky moderné operačné systémy sú aj tak 64-bitové. Prechod od 16-bitových aplikácií (väčšinou 16-bitových inštalátorov) bol trochu bolestivý.
Je tam a Celá dávka vecí, ktoré stále bežia v 32-bitovom režime, dokonca aj od dodávateľov, ktorí to vedia lepšie.
Akékoľvek zjednodušenie je dobré, ale pokiaľ neprerobia skutočné kódovanie inštrukcií, nevidím to ako pohyb ihly.
Muselo by to byť len na trhu dátových centier a byť predávané ako rola VM Hypervisor. Kde vstupuje do hry menej priameho hardvéru.
Nie s ohľadom na kódovanie pokynov.pán E. Mäso povedalo:Je to už desaťročia, čo som robil nejaký assembler, ale nevyčistil x86-64 veľa z toho?
Kliknutím rozbalíte...
V 64-bitovom režime je skutočne preč veľa vtipov a zvláštností; ako niektoré špeciálne registre teraz implicitne obsahujú nulu a niektoré funkcie už nemožno vykonávať starými 8-bitovými spôsobmi, ale musia sa vykonávať podľa (aspoň) 32-bitového veku.
Ale inštrukcie vyzerajú takmer rovnako v 64-bitovom režime. Nové registre (r8 až r15) a nová šírka dát (64 bitov) sú špecifikované s novými predponami pred rovnakými starými, rovnako starými operačnými kódmi. Cieľom bolo pravdepodobne pridať 64-bitovú funkčnosť s minimálnymi zmenami v inštrukčných dekodéroch. Nikto sa neodvážil ohroziť 32-bitový režim, keď Win32 bol v dohľadnej budúcnosti stále dominantným API.
(Je to veľmi odlišné od spôsobu, akým ARM prešiel z 32 na 64 bitov. Prijali zložitosť dvoch rôznych inštrukčných dekodérov a urobili zo 64-bitového režimu takmer úplne novú architektúru. Ako vieme pri spätnom pohľade, mohlo to byť motivované spoločnosťou Apple, ktorá mala v pláne pomerne skoro odstrániť 32-bitovú kompatibilitu zo svojich procesorov. Preto sa plánovalo, že akákoľvek prechodná bolesť skôr ako neskôr zmizne. Historicky spoločnosť Apple nikdy nedovolila, aby spätná kompatibilita prekážala ich plánovanému zastaraniu.)
mpat povedal:Nečítal som celý whitepaper, ale z toho, čo som videl v iných súhrnoch, "režim kompatibility" AMD64 "dlhý režim" bude stále podporovaný.To by malo znamenať, že 32-bitové aplikácie nebudú problémom.
Kliknutím rozbalíte...
Človek by si mal prečítať bielu knihu predtým, ako urobí tvrdenia tak či onak, pretože dokumenty Intelu sú celkom čitateľné.
Áno, biela kniha konkrétne odkazuje na režim User32, v ktorom 32-bitový aplikačný kód Ring 3 naďalej beží bez úprav, ako podobne v ARMv8 môže AArch64 EL1 spustiť kód AArch32 EL0 spôsobom široko kompatibilným s ARMv7, pričom nepotrebuje používať tabuľky stránok ARMv7 alebo iné Vlastnosti.
Je to dosť nové zjednodušenie, no bez akýchkoľvek správ o očakávaných zmenách výkonu alebo nákladov si možno položiť otázku: Prečo sa obťažovať?
Ak človek musí udržiavať, testovať a overovať staršie čipy x86 so všetkým existujúcim vybavením, potom s novou, obmedzenou verziou ušetrí veľmi málo.
Ak je zámerom zachovať iba nové čipy x86-S a prípadne ukončiť plne legacy kompatibilné x86, Očakávam veľký prechod na AMD alebo ARM pre tých, ktorí sa starajú o spätnú kompatibilitu alebo nie. Zdá sa, že x86-S ISA by nebol schopný spustiť 32-bitové staršie operačné systémy vo virutalizácii, pretože hardvérová podpora už neexistuje a emulácia 32-bitového ringu 0 vo virtualizácii je drahá a chybná náchylný.
Možno mi stále nie je jasné, či je zámerom Intelu ISA s nižším výkonom popri plnej x86, alebo ju úplne nahradiť pri zachovaní niektorých starších čipov x86 vo výrobe.
Kompetentnejší ľudia ako ja vidia krok Intelu zameraný hlavne na dátové centrá. Takže veľmi špičkové procesory, ktoré už majú viac špecializovaných funkcií a zložitosť ako desktopové modely. Myslím, že úsilie o overenie tam hore exploduje a prerezanie starého chrastu by pomohlo viac, ako si my, chodci, uvedomujeme.
Nie som procesorový inžinier, ale ten názov ma prekvapuje. X86"S", pre režim Windows "S" v štýle Windows-on-ARM (ale so zachovaním dostatočnej kompatibility hardvéru na umožnenie úplného prepnutia na Windows pre tých, ktorí to chcú)
Nie všetky procesory v zostave by nevyhnutne potrebovali prítomné staršie jadrá, tie, ktoré ich vyžadujú, by potrebovali modely, ktoré ich majú.
hobold povedal:Kompetentnejší ľudia ako ja vidia krok Intelu zameraný hlavne na dátové centrá. Takže veľmi špičkové procesory, ktoré už majú viac špecializovaných funkcií a zložitosť ako desktopové modely. Myslím, že úsilie o overenie tam hore exploduje a prerezanie starého chrastu by pomohlo viac, ako si my, chodci, uvedomujeme.
Kliknutím rozbalíte...
Niektoré z toho v dátovom centre sú poháňané špecializovanými funkciami/urýchľovačmi, ale existuje veľa pracovných zaťažení, kde potrebujete:
Extrémne vysoká hustota jadier a tým aj extrémne energeticky efektívne jadrá, inak by sa požiadavky na teplo a energiu stali ťažkopádnymi alebo by sa nedali zvládnuť. ARM vstupuje do tohto priestoru a to pravdepodobne nestačí na zjednodušenie ISA, aby sa stalo podobným ARM, a nevýhoda procesného uzla sťažuje Intelu konkurovať v oblasti napájania/tepla. Nie nemožné, ale naozaj ťažké. Ak máte pracovné zaťaženie, ktoré vyžaduje jadrá x86 alebo jednotlivé jadrá, ktoré sú skutočne rýchle, AMD to má s vyššou hustotou ako Intel. Alebo máte výpočtovú záťaž GPU, ktorá je vysoko paralelná a CPU je len o správe I/O
Pokúšajú sa prechádzať kurzom na niekoľko nasledujúcich rokov na serveri a najužitočnejšia vec, ktorá by z toho podľa mňa vyplynula, je, že by mohli byť svižnejší. Nie je mi celkom jasné, aký mix serverových produktov bude dominantný o 5 alebo 10 rokov. Zjednodušenie by mohlo viesť k miernym zlepšeniam pri opakovaní nového produktu a úspora každého posledného kúska kremíka pomáha. Je pravda, že v priestore servera je šanca, že niekto potrebuje zaviesť 16-bitový OS alebo dokonca 32-bitový OS na modernom hardvéri, mizivo malá.
Podľa bielej knihy bude podpora pre krúžky 1 a 2 odstránená. Z pamäte boli pridané v nádeji, že prilákajú DEC na port VMS na x86. Myslím, že o 30 rokov neskôr x86-64 port OpenVMS ich nakoniec nepoužíval...
presne tak. Dokonca aj teraz najnovšie CPU od Intelu alebo AMD stále podporujú všetky bláznivé režimy z 8-bitovej, 16-bitovej a skorej 32-bitovej éry.hobold povedal:Odstránenie zložitých starých vecí znižuje zložitosť. To šetrí námahu pri testovaní a overovaní. To má tendenciu znižovať útočné plochy, pretože to, čo zostáva, dostane v dostupnom časovom rámci viac testov.
Kliknutím rozbalíte...
Chránený režim a pamäťové segmenty používané pred prijatím x86-64 sú šialený, zahŕňajú pol tucta registrov na sledovanie, kde sa nachádza váš kód, údaje alebo zásobník, a viacvrstvový preklad adries pamäte navrchu.
Zbaviť sa úplného odpadu pred x86-64 by bolo veľkým prínosom pre dizajnérov čipov a ich overovacie tímy.
Ale všetky tieto veci sú hotové a tranzistorový rozpočet pre tieto staré režimy je malý. Zdá sa veľmi nepravdepodobné, že skutočne dôjde k výraznému zlepšeniu rýchlosti. Intelu by to umožnilo minúť menej peňazí na kontrolu kvality, ale nemalo by to pre nás žiadny prínos.
Pochybujem, že ide o počty tranzistorov alebo surovú rýchlosť, ale skôr o zložitosť. Pre Intel to musela byť nočná mora, keď sa pokúšal identifikovať a uzavrieť cesty pre útoky na bočných kanáloch alebo všetky spôsoby, akými môžu tieto rôzne režimy narušiť ich bezpečnostný model.
Hlúpa otázka - aj keď existuje platný útok proti chránenému režimu, existuje skutočne životaschopný útočný povrch - ako v prípade čipov, ktoré skutočne bežia v tomto režime?
Len veľmi málo takýchto útokov využíva existujúcu funkčnosť zamýšľaným spôsobom – Meltdown bol výnimkou, nie pravidlom. Zvyčajne ide o jemné chyby. Ak je v špecifikácii N zákutí a zložitých malých detailov, potom existuje N*N možných interakcií medzi akýmikoľvek dvomi takýmito malými detailmi. Možno ich všetky otestujete. A čo interakcia tretieho detailu? Potom sme pri N*N*N kombináciách.Mad Doggie povedal:Hlúpa otázka - aj keď existuje platný útok proti chránenému režimu, existuje skutočne životaschopný útočný povrch - ako v prípade čipov, ktoré skutočne bežia v tomto režime?
Kliknutím rozbalíte...
Funkcia nemusí byť ani aktívna, aby mala vplyv na iné časti stroja.
GeneralFailureDriveA povedal:Áno, ale len ťažko si dokážeme predstaviť, že Intel už nebude predávať plnohodnotné x86 čipy, ktoré dokážu spustiť staršie operačné systémy, pretože toto je jeden z mála zostávajúcich dôvodov, prečo kúpiť Intel – že spätná kompatibilita je svetová vedenie.
Kliknutím rozbalíte...
Silne mám podozrenie, že celkový adresný trh na podporu skutočného režimu v hardvéri, najmä pre najnovšie procesory, je v skutočnosti nulový. Ak je to skutočne potrebné, je to potrebné pre kompatibilitu s dvojcifernými mhz CPU, čo znamená, že v podstate je nemožné dostať niečo príliš pomalé a nemá zmysel sa trápiť s tým najnovším CPU.
Vidím nejaké potenciálne problémy pri emulácii, ak sa očakáva výkon v reálnom čase, takže nie je automaticky pravda, že môžete spustiť DOSBox vec priemyselného riadenia, ale napriek tomu je viac než postačujúce použiť nejaký posratý procesor Atom, a ak pre to stále existuje trh, nebude ťažké si ho udržať okolo.
GeneralFailureDriveA povedal:Ak je zámerom zachovať iba nové čipy x86-S a prípadne ukončiť plne legacy kompatibilné x86, Očakávam veľký prechod na AMD alebo ARM pre tých, ktorí sa starajú o spätnú kompatibilitu alebo nie. Zdá sa, že x86-S ISA by nebol schopný spustiť 32-bitové staršie operačné systémy vo virutalizácii, pretože hardvérová podpora už neexistuje a emulácia 32-bitového ringu 0 vo virtualizácii je drahá a chybná náchylný.
Kliknutím rozbalíte...
Chápem to tak, že pred podporou virtualizácie hardvéru VMWare emulovalo ring 0 pomocou emulátora v štýle JIT, ktorý, pokiaľ viem, fungoval dobre. Môže to byť drahé z výpočtového hľadiska, ale to nás privádza späť k tomu, aká obrovská výhoda je v podpore dedičstva aplikácie na súčasnom hardvéri, konkrétne, že je oveľa rýchlejší ako čokoľvek iné dnes, že je to v podstate nemožné príliš pomalý.
hobold povedal:Kompetentnejší ľudia ako ja vidia krok Intelu zameraný hlavne na dátové centrá. Takže veľmi špičkové procesory, ktoré už majú viac špecializovaných funkcií a zložitosť ako desktopové modely. Myslím, že úsilie o overenie tam hore exploduje a prerezanie starého chrastu by pomohlo viac, ako si my, chodci, uvedomujeme.
Kliknutím rozbalíte...
Základný dizajn jadra sa v skutočnosti veľmi nelíši medzi dátovým centrom a klientom. V každom prípade nie pre časti relevantné pre staršie režimy.
rek povedal:Zaujímalo by ma, či sa to nakoniec stane odpoveďou Intelu na platformu Windows-on-ARM. Niečo, čo môžete vyskúšať a skontrolovať energetickú účinnosť (zjednodušením uarch), ale zachovať kompatibilitu s akoukoľvek primerane modernou aktuálnou aplikáciou pre Windows.
Kliknutím rozbalíte...
Z toho, čo som videl, si nemyslím, že to bude mať podstatný vplyv na energetickú účinnosť, pretože staršie režimy sú silne mikrokódované a v podstate ich nikto nepoužíva.
rek povedal:Nie som procesorový inžinier, ale ten názov ma prekvapuje. X86"S", pre režim Windows "S" v štýle Windows-on-ARM (ale so zachovaním dostatočnej kompatibility hardvéru na umožnenie úplného prepnutia na Windows pre tých, ktorí to chcú)
Kliknutím rozbalíte...
Silne o tom pochybujem, pretože z toho, čo som videl, by ste mohli nainštalovať existujúci 64-bitový Windows na čip x86S bez akýchkoľvek zmien alebo dokonca vedomia operačného systému. V modernom x86 počítači s UEFI ho firmvér okamžite prepne do dlhého režimu skôr, ako urobí čokoľvek iné, a odovzdá OS už v dlhom režime. To znamená, že všetky časti sú na to pripravené už dnes, bez toho, aby si Windows/Linux/čokoľvek uvedomovali rozdiel.
Myslím si, že ľudia, ktorí o tom hovoria ako o nejakom novom presadzovaní alebo presune ISA na ARM, to veľmi preháňajú. Toto všetko robí len zosúladenie podporovaných prevádzkových režimov s režimami, ktoré ľudia skutočne používajú. Chcú zrušiť veci, ktoré musí Intel platiť za údržbu, ale prakticky nikto im neplatí za ich používanie.
Predpokladám, že Intel sa pozerá na procesory Apple založené na ARM a je trochu nervózny z rýchleho vývoja vo výkone, pričom sa snaží skutočne vyvinúť základnú architektúru x86 bez zníženia spotreby energie šialený. Pokiaľ môžem povedať, ARM tam nie je na výkon s jedným vláknom, ale softvér začal byť viacvláknový, keď sme dostali viacjadrové procesory dokonca aj v rozpočtovom segmente.Megalodon povedal:Myslím si, že ľudia, ktorí o tom hovoria ako o nejakom novom presadzovaní alebo presune ISA na ARM, to veľmi preháňajú. Toto všetko robí len zosúladenie podporovaných prevádzkových režimov s režimami, ktoré ľudia skutočne používajú. Chcú zrušiť veci, ktoré musí Intel platiť za údržbu, ale prakticky nikto im neplatí za ich používanie.
Kliknutím rozbalíte...
Keď dokážete zahodiť 32 alebo 64 jadier v CPU bez toho, aby sa váš energetický rozpočet zbláznil, predstavujem si, že AMD a Intel sa obávajú, ako môžu pokračovať v súťaži? Najmä ak sú CPU aj relatívne lacné na výrobu.
Megalodon povedal:Ktorá z nich by podľa vás mala byť problémom? Inštalátor linuxu môže zobraziť textovú výzvu, ale CPU je stále v dlhom režime.
Kliknutím rozbalíte...
Spočiatku nebolo jasné, či bude podpora pre 32-bitové aplikácie robustná alebo či bude vykonaná prostredníctvom emulácie a keďže ide o Intel spitballing, predpoklad je, že implementácia by bola plynulá a hardvér by podporoval 32-bitový režim natívne. Naozaj nenaznačujem, že prechod by bol bolestivý pre 32-bitové aplikácie pod 64-bitovým operačným systémom bežiacim na hardvéri 64S, ale skôr tým, že prechod na 64-bitové bol bolestivé pre 16-bitové aplikácie, pretože spätná kompatibilita Microsoftu výrazne chýbala.
Predovšetkým bolo veľa inak fungujúcich 32-bitových aplikácií, ktoré boli zmarené, pretože inštalátori, ktoré používali, sa pri prechode z 32-bitovej verzie zo 16-bitovej dotkli. Predpoklad bol, že inštalačný program bude spustený iba raz a nikto netestuje inštalačný softvér, ale to sa vrátilo, aby ho uhryzol, keď ste nemohli nainštalovať.
Veci sú tentokrát trochu iné, ale nikdy nepodceňujte šancu, že niekto má niekde zvláštny starý kód...
wireframed povedal:Predpokladám, že Intel sa pozerá na procesory Apple založené na ARM a je trochu nervózny z rýchleho vývoja vo výkone, pričom sa snaží skutočne vyvinúť základnú architektúru x86 bez zníženia spotreby energie šialený. Pokiaľ môžem povedať, ARM tam nie je na výkon s jedným vláknom, ale softvér začal byť viacvláknový, keď sme dostali viacjadrové procesory dokonca aj v rozpočtovom segmente.Keď dokážete zahodiť 32 alebo 64 jadier v CPU bez toho, aby sa váš energetický rozpočet zbláznil, predstavujem si, že AMD a Intel sa obávajú, ako môžu pokračovať v súťaži? Najmä ak sú CPU aj relatívne lacné na výrobu.
Kliknutím rozbalíte...
Intel nemusí hľadať tak ďaleko ako ARM, tie už za AMD zaostávajú v hustote a energetickej účinnosti. Obaja zaostávajú za ARM, ale Intel je v nezávideniahodnej pozícii, že momentálne zaostáva. Zdá sa, že robia pokroky v procesných uzloch a práve to pomôže tomuto problému viac, než len mierna zmena architektúry.
Pracovná záťaž, ktorú má väčšina ľudí, nie je lineárna. V určitom okamihu jednoducho nepotrebujete viac jadier. Intel si v súčasnosti myslí, že 8 P-jadier stačí pre ich najvyšší produkt pre stolné počítače. Extra E-jadrá dnes určite zasiahli klesajúce výnosy, rovnako ako prechod z 32-jadrového ARM CPU na 64-jadrový ARM CPU. To je veľa vlákien, ktoré čakajú na to, čo urobia, keď to, čo naozaj chcete, sú rýchlejšie vlákna. Pre pracovné zaťaženia, ktoré sa škálujú, už existujú servery založené na ARM.
Možno nebudete chcieť tieto rýchlejšie vlákna v procesore, ktorý dosahuje vrchol ~ 300 W, pripúšťam, že účinnosť ARM je predajné miesto, ale vypustenie 16-bitového režimu nepohne ihlou na tepelných alebo výkonových parametroch Intelu efektívnosť.
Nevarre povedal:Spočiatku nebolo jasné, či bude podpora pre 32-bitové aplikácie robustná alebo či bude vykonaná prostredníctvom emulácie a keďže ide o Intel spitballing, predpoklad je, že implementácia by bola plynulá a hardvér by podporoval 32-bitový režim natívne. Naozaj nenaznačujem, že prechod by bol bolestivý pre 32-bitové aplikácie pod 64-bitovým operačným systémom bežiacim na hardvéri 64S, ale skôr tým, že prechod na 64-bitové bol bolestivé pre 16-bitové aplikácie, pretože spätná kompatibilita Microsoftu výrazne chýbala.Predovšetkým bolo veľa inak fungujúcich 32-bitových aplikácií, ktoré boli zmarené, pretože inštalátori, ktoré používali, sa pri prechode z 32-bitovej verzie zo 16-bitovej dotkli. Predpoklad bol, že inštalačný program bude spustený iba raz a nikto netestuje inštalačný softvér, ale to sa vrátilo, aby ho uhryzol, keď ste nemohli nainštalovať.
Veci sú tentokrát trochu iné, ale nikdy nepodceňujte šancu, že niekto má niekde zvláštny starý kód...
Kliknutím rozbalíte...
To nebola chyba Microsoftu. To bola chyba AMD, že zrušila väčšinu 16-bitovej podpory v 64-bitovom režime. To, čo fungovalo dobre v 32-bitovej verzii, sa zrazu zlomilo v 64-bitovom prechode.
To mi za tie roky spôsobilo toľko bolesti. Naozaj by som chcel nájsť predsedu AMD zodpovedného za toto odvážne rozhodnutie a potrestať ho dôkladne.
Budete musieť prejsť cezo mňa. Teda vlastne nie, keďže nerobím pästné súboje.malor povedal:To nebola chyba Microsoftu. To bola chyba AMD, že zrušila väčšinu 16-bitovej podpory v 64-bitovom režime. To, čo fungovalo dobre v 32-bitovej verzii, sa zrazu zlomilo v 64-bitovom prechode.To mi za tie roky spôsobilo toľko bolesti. Naozaj by som chcel nájsť predsedu AMD zodpovedného za toto odvážne rozhodnutie a potrestať ho dôkladne.
Kliknutím rozbalíte...
Ale som rád, že AMD využilo príležitosť vyčistiť niektoré z najstarších vecí. IMHO sa to týkalo kódu, ktorý bol taký starý, že všetci príslušní programátori už dávno prešli. Strih motivoval novú generáciu ľudí, aby to urobili celé, dúfajme, že s niekoľkými lekciami získanými od veteránov.
Emulácia je enormne pomalšie ako spustenie priamo na hardvéri.
Získali sme určité zjednodušenie. Získali sme nové školenia o starých problémoch. Získali sme zníženie starého technického dlhu. Ale áno, „náklady na prechod“ sú reálne a museli sme ich zaplatiť.malor povedal:Z toho vynechania sme nič nezískali.
Kliknutím rozbalíte...
Verím však, že nie celý starý kód je „vyskúšaný“; nejaký starý kód je jednoducho zabudnutý, a teda v podstate mŕtvy. Takáto hniloba sa vždy vráti, aby vás v určitom okamihu poštípala, a bude to bolestivejšie, čím dlhšie budete upratovanie odkladať.