".. Eliminovány mají být například úrovně privilegií ring 1 a ring 2 (moderním softwarem nepoužívané) .."
Poděkování zasílejte společnosti micro$oft, která to nevzládla zavést od roku 1985.
Na druhou stranu se zavedly Ring -1 a Ring -2 nedostupné z úrovně OS.
".. Intel by mohl zrušit například podporu pro instrukce MMX a x87 (a jejich registry) .."
Před příchodem CPU Pentium (a obdobných od jiných výrobců) se FPU na strojích, kde nebyla přítomná x87 jednotka, řešily emulací. Ono to někde v kódu ještě bude.
".. Vypadá to, že čistě usermode softwaru by se nemusel dotknout moc, a tudíž by rozbitých starších programů nemuselo být tak moc .."
Já bych zas tak optimistický nebyl.Vzhledem k tomu, co tnadem M$+Intel (ne)dokázal udělat, si raději nějaký stroj raději nechám v záloze.
Já teda nadšení nesdílím. Čas od čas ještě potkávám i 16-bit aplikace (které se dnes řeší buď emulací/virtualizací, provozem 32bit OS nebo hackem NTVDM). Dále by to zásadně ovlivnilo možnost emulace a virtualizace starých prostředí (nešlo by spustit nic až do Win XP x64), tj. všechny DOSy, Win9x, apod. by potřebovaly procesorový emulátor, zatím co dnes jim stačí daleko méně.
A ačkoli sám takové věci používám už jen sporadicky (v podstatě jen DOSbox), je to pro mě docela velké minus, pokud by se takový "ořezaný" CPU měl stát srdcem mého nového PC.
Mimochodem, nekolikrat zminovany ARM, ten do toho take poradne rizl, ale vyuzil k tomu prechod ARMv7 -> ARMv8. Nikdo neplakal, bo si poradny ARMv7 MCU stale muze koupit. Predpokladam, ze Intel to udela podobne a v nekterych procesorech pojede plne historicka ISA. Tipnul bych v tech pro embedded. Jinde to nema vubec smysl...
Celkem souhlas s tynytem, jen bych si nebyl jisty, jestli vsechny ty x86 legacy funce jsou pouze v microcode, rek bych, ze nektere budou i zadratovane. Ale to je jedno, to se asi prenasi z generace na generaci vice mene beze zmen. Taky si nemyslim, ze se timto procesory nejak znatelne zrychli nebo se snizi spotreba. Na blbou 386/486 stacilo mene nez milion trandu, neska je jich v CPU x miliard, takze to odpadne jen nepatrna cast.
Hlavni symsl pro intel tedy vidim v ekonomicke uspore, protoze to testovani vsech moznych rezimu zabere urcite nemalo casu a pripravy tech testu a jelikoz se uz leta intel placa ve srackach, klesa mu marze, tak reze, kde se da. AMD je v pohode, tak k tomu nema duvod. Pokud by intel nabizel jen x86-S a AMD stale plnohodnotne x86, tak by to byl pro me duvod ke koupi AMD. Predpokladam, ze intel v embedded segmentu bude i potom nabizet nake low-end atomy s klasickym x86 jadrem. Me by treba prislo prijatelnejsi reseni, kdyz by mel CPU aspon jedno plne x86 jadro (to ktere startuje po zapnuti) a zbyla x86-S, ostatne uz ted ma big-little s ruznyma ISA. Dal se nabizi otazka, kdyz uz teda chtej kompatabilitu zbourat tak dokonale, ze bude treba uprava i v 64bit OS, tak proc se na to uz rovnou nevy.... a nejdou do nake arch. nezatizene minulosti treba ARM64 ci RiscV (intel uz zkousel IA64 a nejak se nechytlo, ze)...
BTW ArcaOS vychazejici z OS/2 predpokladam stale vyuziva vsechny ring 0-3, takze neni pravda, ze by to nikdo nevyuzival. System vice CPL mel zajistit vetsi bezpecnost systemu, ale asi jediny IBM to opravdu implementoval, v MS se na to vykakli, tam nebyla bezpecnost a stabilita priorita...
Tohle je neslýchané, takhle brutálně zlikvidovat zpětnou kompatibilitu. Doufám, že se jim to nepovede a že to skončí v propadlišti dějin jako Intel Itanium. S Itaniem tenkrát taky narazili, právě kvůli nekompatibilitě s x86. S řešením pak přišel AMD, který vytvořil x64, zpětně kompatibilní s x86, a to mu získalo pozici. Intel to pak začal poslušně vyrábět taky, jinak by neměl šanci. Historie se holt opakuje. Dnes jsme sice o 20 let dál, ale amputovat i 32bitový režim mi přijde příliš.
Argument vyšší efektivity je nesmyslný, přítomnost "starých struktur" v CPU nijak nezatěžuje, nejsou-li aktivní, a jejich složitost je marginální oproti těm současným.
Ze strany Intelu vidím jenom snahu vydělat na nové nekompatibilní platformě a získat náskok, než ji začnou dělat ostatní výrobci, pokud by se tedy ujala. Umím si živě představit, jak Microsoft vydá Windows třeba 13, která nic jiného než x86-s nebude podporovat. Plus nesmíme zapomenout na vydatnou pomoc indoktrinovaných ajťáků, „IT apoštolů“ a líných lepičů kódu, kteří do uživatelů budou vytrvale hustit, jak je důležité stále upgradovat. Oběť bude opět uživatel, který bude nucen zase kupovat nový HW a SW a solit prachy. No, je už zvyklý.
Na jednu stranu je to důvod, proč architektura x86 je tu s námi tak dlouho a je stále defacto standardem u desktop PC. Na druhou stranu je to přesně důvod, proč v jiných sektorech naprosto zoufale propadla a čím dál víc ji dýchají na krk ostatní v jejích silných oblastech.
Vyhnání kostlivců ze skříně je už dlouho na pořadu dne a podobně jako ostatní si myslím, že Intel je ještě velmi opatrný v tom, do čeho chce říznout, aby se to rovnou nesmetlo ze stolu.
Dneska uz mame na stole takovy vykon, ze i jednoduche qemu s plnou emulaci instrukci by dokazalo emulovat vas 16bit v plne a vyssi rychlosti. Staci takto? A nebo se musite nadsene koukat jak vas 16bit kod jede 895x rychleji nez v roce 1988? Pokud ano doporucuju koupit posledni nejaky kousek s plnout ISA. Ono, asi tady mluvime nekde o letech 203x takze zadny spech...
To si úplně jistý nejsem, ty části kódu tam mohly být ještě pár let po tom, co se koprocesor stal běžnou částí i nejlevnějších CPU, ale to se přece stalo už dost dávno, takže potom už to ztratilo smysl. Je spíš otázka jakého SW by se vypuštění čistých x87 a MMX vlastně týkalo a jak dlouho po zavedení novějších vektorových instrukcí se čisté MMX přestaly používat.
A ty znáš nějaký rozšířený OS pro ARM vyjma Linuxu, který je pokaždé hromadou dobrovolníků znovu a znovu překompilován do různých dister? Podívej se i na ten prašivej Android, tam se na XDA pinoží stovky aktivsitů, aby dosáhli spuštění Androidu na tom či onom kusu HW. A proč? Protože ani ten bootloader nemají všichni stejný! Další level jsou drivery, které nejsou opensource a výrobci je nekompilují pro všechny varianty HW.
Vy jste se všichni dočista zbláznili!?
"Dal se nabizi otazka, kdyz uz teda chtej kompatabilitu zbourat tak dokonale, ze bude treba uprava i v 64bit OS, tak proc se na to uz rovnou nevy"
Podle mě to porušení kompatibility v tomhle případě bude spíš malé, takže budou třeba v OS relativně malé* změny - ale budou nutné. (* o tom použití v linii OS/2 a ArcaOS jsem nevěděl, pro ten OS to asi bude problém a asi bude potřebovat větší rewrite)
Operační systémy se (aspoň teoreticky) většinou s hardwarem nasazují pořád nové a aktuální, takže to zřejmě berou tak, že požadavek nové verze OS není takový problém. Naopak zásadní bude, aby zůstala funkčnost userspace aplikací a pokud na x86-S poběží normálně starší x64 a dokonce x86 (32bit) aplikace, tak by bylo to nejdůležitější z hlediska kompatibility zachováno. Uvidíme samozřejmě, jestli se to tak povede udělat. U spousty softwaru se ještě může ukázat, že měl nějaké návaznosti na hlubší součásti OS a bude mít problémy.
TL;DR - jestli tomu dobře rozumím, tak jejich cílem je ty změny dělat tak, aby se to co nejmíň dotklo userspace, zatímco rozbití kompatibility, které je relevantní jen pro kernel, jim tolik nevadí.
Víš, Sidey, celá platforma x86 je postavena na evoluci, nikoli revoluci. A divil by ses, kolik toho "starého smetí" ještě všude možně funguje. A celé to vytváří ekosystém. Neexistuje jediný racionální důvod se zbavovat těchto legacy věcí, už jen proto, že to v moderním procesoru díky mikrokódu prakticky ničemu nevadí. Celý svět jede na optimalizací nákladů, neřeší se to, co funguje, dokud to funguje, jen u Intelů se nyní snaží dělat vlny, protože mají průser za průserem.
Navíc tvůj příměr je poněkud invalidní.
Které sektory máš přesně na mysli, a proč si myslíš, že PC architektura by měla být standardem/základem např. u mobilů?
Dále bych rád věděl, proč by toto "vyhnání kostlivců" mělo být vůbec na pořadu dne? Dělá to někomu problém, že ten procesor umí fungovat jako i8086? S EFI se v podstatě do V86 nebo Legacy mode ani nedostaneš, pokud nechceš. A konečně: kvantifikoval někdo to zlepšení, pokud by se tyto legacy věci vyhodily? Proč tam není aspoň nějaké bezpohlavní procento? ????
A nakonec tu je jedna svatokrádežná otázka: když už měníme vnitřek, proč se rovnou nepřehodit na nějakou tu podle vás progresivní (progresivistickou) platformu typu ARM? A proč to už dávno nenastalo, těch pokusů WinOnARM tu už bylo několik... že by to bylo tím, že SW emulace je prostě vždycky fuj (a snést ji dokáží pouze submisivní jablečnoidi?) Anebo třeba tím, že ten ARM reálně vůbec x86 nekonkuruje/není schopen konkurence Wintelu?
To není tak úplně pravda. Ta emulace je nutná dvojí - kvůli adaptaci rychlosti (a již neexistujícího HW, např. zvukovky) a pak podle typu běhového režimu. Nicméně na x86 platformě existuje režim dynamic, který používá přímé instrukce fyzického CPU (na PC) a je defaultně používaný pro protected mode a je součástí defaultního "auto" režimu. A je to celkem logické, protože tam není výkonová penalizace.
https://www.dosbox.com/wiki/Configuration:CPU
Tohle mě taky dostává. Všude se řeší efektivita a výkon a pak najednou "emulace stačí" a že to žere 10x tolik? To taky nevadí.
Ptám se znova: čemu ty legacy modes konkrétně vadí a jak se to pozitivně projeví pro mě, jako spotřebitele? A fakt nechci slyšet ty budovatelské písně o tom, že to je starý a že přijde mladej, a to bude sekáč!
Mirite trosku mimo, ale i tam odpovim. Podivejte se co s ARMv8 prislo: SBSA. A proces pokracuje, doporucuju https://marcin.juszkiewicz.com.pl/2020/10/12/standards-in-arm-space-part-i/
Proste obcas je dobre neco orezat aby vznikl prostor pro novou vec. Smirte se s tim, takovy je zivot. Ne nadarmo se rika, ze zivot je zmena... :-)
FPU je součástí CPU od Intel Pentium. U ostatních výrobců bych to musel hledat.
Na druhou stranu, proti 8087~487 už byly některé instrukce z FPU jednotky vypuštěné. Z důvodů kompatibility tak musí být alespoň v minmální míře být přítomen kód pro emulaci těch instrukcí.
MMX sdílely registry a část obvodů s FPU. V praxi tak mohly být použity buď FPU instrukce, nebo MMX.
SSE a následující byly udělány lépe.
ad a) To jsem nikdy neřekl, jen to, že se i přes velké pokusy Intelu tak stalo.
ad b) Jsem vývojář, vidím to z druhé strany. Podpora legacy komponent (takhle prehistorických) může být reálně velká překážka pro další vývoj, nedělám si srandu. Hází ti to neustále vidle, stojí to peníze. Dřív nebo později se toho zbavíš, protože mušíš.
Klientům to samozřejmě nevadí, ale málokomu by to vůbec chybělo, v tom to je.
ad c) Bezpečnost nekvantifikuješ, velký výkon ani efektivitu bych pořádně nečekal.
Zbytek už mi přijde jako zbytečný flame, já se tady nesnažím hádat, ale diskutovat.
Normal: The program is interpreted instruction by instruction.
Dynamic: The program instructions are (in blocks) translated to host processor instructions that execute directly.
Důležitá jsou slova translated a in block.
To klidně mohu napsat, že java běží nativně (díky JIT kompilaci).
Na to je pomerne jednoducha odpoved. Pokud potrebujete realne behat historicky software, proc tak neucinit na skutecne historickem hardware? Mame 2023. i386 je tady od roku 1985. A AMD64 od roku 2002. Cili prvni skoro 40 let, druha 20. Jak casto ten historicky software behate a hlavne kolik vam ten software vydelava? Pokud je to jen pro konicek/zabavu, doporucuju ten historicky hardware at je nostalgie uplna...
Jinak Intel reze velmi opatrne. 32bit emulace budou stale vehat ve virtualizaci, takze pokud budete mit moznost upgrade ze '70tych do '80 na i386, vrele doporucuju. :-)
Mám i konkrétní příklad. Kamarád dělal v energetice a někde v rozvodně jim odešel systém dělaný na míru 486. Ty už se pochopitelně koupit nedaly, tak sháněl HW emulaci pinově a elektricky kompatibilní. Takové věci existují. A i když to stálo mraky peněz, nahradit ten HW a hlavně napsat znovu celý SW by stálo řádově víc. Takových situací je třeba 1000x nebo i výrazněji méně než běžných uživatelských a firemních PC a serverů, ale jsou i na hodně důležitých pozicích. Podobně to je třeba u lékařských přístrojů a takových dalších se dá najít hodně.
proč mi z tvých odpovědí přijde že máš odpor k jakémukoliv čištění? Žádná kompatibilita tu nebude napořád. Wintel aliance je vyjímkou, jinde se s tím moc nemažou a taky to jde, viz Apple. Tak nějak to připomíná rčení "smrádek ale teploučko". Nejsem také pro nějaké radikální akce ale stará zátěž kterou využívá promile uživatelů je ideální kandidát na odklizení.
Jednoduse, ekonomicky, pro pochopeni. 16/32 bit v procesoru vyzaduje jistou funkcionalitu, ktera se musi pred vydanim otestovat a hlavne ktera tam musi byt. Neni to jako se softwarem, ze se neco zkopiruje a ono to beha. U hardware je to trosku jinak a navrh musite mezi procesy "portovat". Cim vic veci portujete tim vetsi usili vas to stoji.
To si myslim, ze by mohlo byt jasne?
A ted ekonomicky: kolik % uzivatelu mych produktu (myslim jako Intel) potrebuje tuto funkcionalitu? Rekl bych, ze se vysledek pruzkumu bude blizit 0.
Vyplati se mi to tedy a nebo nevyplati a nastal cas riznout? Odpovezte si sam...
Jeste jedna vec. Uvedomujete si, ze Intel x86-s nasadi nejdrive u serveru/cloud provideru, ktreri skutecne nic takoveho jako vy nepotrebuji a naopak budou radi, kdyz se nejaka ta vrstva vyreze protoze s tim maji sami sve bezpecnostni problemy? A taky ze budou radi, ze se ty tranzistory pretavi treba na vetsi cache a nebo lepsi front-end?
Klienti prijdou az potom a naposled embedded. Takze pokud pujdete do embedded, myslim, ze budete v klidu. Intel u soucasnych cipu uvadi dostupnost 2035.
Nesouhlasím. U x86 byl hlavně problém v přístupu do RAM, který se stával dost komplikovaný. Ale to se snad už 64 bit režimu netýká a tedy ani nových aplikací. Nicméně Intel s AMD nejsou jediné, kdo tahá minulost za sebou. I nejnovější IBM Power 10 umí plně HW instrukce System 360. A je to bráno jako výhoda.
ale to se tváříte jako by k tomu mělo dojít do roka. Tohle je první iniciativa a než to probublá do reálu ještě pár generací hw tu bude. Tak ikdyby si určili jako hranici zavedení rok 2028 tak kdo v té době bude používat tak starý hw který už bude ikdyž funkční na pokraji životnosti? Díly také hned nezmizí, takže klidně další dekádu na starém mohou lidi fungovat. Dál už to bude čím dál rychleji odcházet.
A já se tě musím znova zeptat: nemyslíš, že právě tato důsledná a co nejdelší kompatibilita je důvodem dlouhodobého úspěchu této platformy? Já neříkám, abychom udržovali starou ISA s 8/16 přerušeními. Já říkám, že ořezávat běhové módy procesoru je nesmysl, protože většina z toho je stejně jen mikrokód, který nemá prakticky žádný vliv na rychlost nebo počet tranzistorů. Je to jen finanční náklad pro vývoj, a myslím, že poměrně marginální oproti moderním rozšířením, protože je na dnešní poměry primitivní.
Proto jsem se ptal, jaký benefit z toho plyne pro mě jako uživatele. Jsem ochoten akceptovat jakýkoli myslitelný argument, ale zatím tu žádný nezazněl, kromě toho vágního "je to skvělý, už aby to bylo!" A aby to nebylo málo, tak to "promile" uživatelů jsou "kupodivu" takové ty "neviditelné" ale o to důležitější systémy, které se většina populace už naučila ignorovat, protože ony jednoduše fungují. Jistě - bezcennému gamesníkovi s jeho nadupaným rigem to je jedno, protože jeho gamesky to neovlivní...
A dále: Apple sem moc netahej, já jsem zažil první rosettu s prvními PPCmacky a bylo to peklo, ostatně jako celý apple ekosystém je a byl peklem. Ti jsou na ty jablečné sračky zvyklí, a když něco nefunguje, tak to prostě nefunguje a je to tvá chyba.
No a není snad JIT nativní kód? Že je kompilován ad-hoc až při běhu aplikace, to je přece fuk, ne? Cílem (tím praktickým, proč se to vůbec dělá) je vždy totéž: odstranit vrstvu interpretru (emulátoru) a jeho overhead, a tím zásadně (!) zrychlit vykonání kódu.
Režim Dynamic je použit právě kvůli rychlosti a využívá funkčnosti platformy x86 (na jiných platformách není dostupný). Jakmile nový CPU ořežeš, tento režim použít nepůjde. To je celé.
Sorry, asi jsi nepochopil o čem je řeč. Že výrobce musí otestovat mikrokód a všechny režimy, to je jasné a máš to napsáno výše (finanční náklad pro vývoj). Ale to se jedná o fixní náklad, který se rozpouští ve vyrobeném množství. A opravdu si nemysli, že se něco "portuje" - v drtivé většině případů se pouze iteračně vylepšuje.
A teď ekonomicky: opravdu bude stát za to celou touhle šarádou odepsat spousty SW a OS? Já netvrdím že ne, já se ptám, co to přinese mně, jako spotřebiteli. Ptám se na konkrétní věc a dostávám jen nicneříkající slátaniny.
Já to chápu, že to nebude hned a jednou k tomu dojde. Ale jen jsem měl pocit, že musím trochu protiargumentovat těm jásavým výkřikům "včera bylo pozdě" a "stejně to jen brzdí."
Nicméně když se řekne "A," tak by mělo zaznít i "B" - tedy když tvrdí, že to zpomaluje, tak by měl přijít i určitý závazek, že to povede ke zrychlení. Já si ale myslím, že to je jen způsob jak ušetřit na vývoji.
V historii IT byly pokusy udělat CPU, který by jako instrukční sadu používal Java byte-kód. Tam by Java opravdu běžela nativně.
Nějak to zašlo na úbytě, takže zbyly 2 možnosti: interpretace po 1 instrukci, nebo překlad většího bloku instrukcí.
Je mnohem jednodušší převést
ld AL, 8-bit
dec AL
jnz point_1
na
ld XEAL, 64-bit
dec XEAL
jnz point_1
než se to snažit (za běhu) přeonačit na ne x86 kód.
".. Jakmile nový CPU ořežeš, tento režim použít nepůjde .."
Proč by nemělo?
Dynamic režim má svůj overhead. Jen je znatelně menší, než při interpretaci každé instrukce zvlášť.
Normal má větší overhead, ale je univerzální a multiplatformní.
O výkon při emulaci bych se zas tak moc nebál. Když Ryzen Z1 na 8W zvládne spouštět PS3 hry.
Takže zaplevelení EFI vyřeší odplevelení CPU? A to znamená přesně co? Že "zaplevelené" EFI přestane fungovat? Kdo zaplatí vývoj?
Já bych fakt rád slyšel alespoň jeden RACIONÁLNÍ a na faktech postavený argument, proč je nutno (nebo proč je výhodné) pro koncového spotřebitele zbavit se kompatibility se staršími x86 režimy? Není pravda totiž to, že to "nikdo nepoužívá."
Jak to ulehcuje zivot? Rekneme, ze je nejaky klasicky standard kde se mnozstvi chyb (i kritickych) pocita na radky kodu. Rekneme, ze odstranenim 16/32bit z EFI orezeme par stovek/tisic radek kodu. Cili z pohledu uzivatele snizujeme statisticky sanci na i kriticke chyby.
Vzhledem k tom, ze Intel ma bezpecnostnich hrichu obrovske mnozstvi, lidi v cloudu budou jen radi pokud trosku zmensi "plochu pro utok".
MacOS je uzavřený systém, který jen za dobu co ho znám/používám vyměnil HW 4 platformy a podporuje jen to, co sám vyrábí (pokud sis někdy zkusil postavit vlastní Hackintosh, tak to je taková pěkná sonda do této prašivé platformy). To není argument. *BSD je analogie s Linuxem, jen trochu (hodně) opožděná, protože počet vývojářů těchto platforem je omezený - něco o tom vím, protože s BSD jsem v *NIX světě kdysi začínal (cca 1996) a ty podmínky se spíše zhoršují (až tak, že např. TrueNAS postupně migruje z FreeBSD na Linux.) Tady ti tedy nefunguje ani ta podpora nového, natož aby byli schopni řešit podporu celé šíře HW.
A ARMové Windows? Vyjma tabletů s pečlivě vybraným HW (pro který jsou drivery) je to mrtvá platforma, tam pořádně nefungují ani x86 programy.
Upřímně řečeno, ani jsem nečekal, že vytáhneš tyhle argumenty, které tě potopí ještě víc.
Boze chran! i486? Proc bych to delal? Tremont/Gracemont jsou preci pekna jadra a v pripade Tremontu bezi i v pomerne peknych procesorech. Proc bych si mel kupovat skodu favorit z roku 1989? Ekonomicky mi to nedava smysl.
Jedina aplikace, kdy by to davalo smysl je embedded kde si proste nemuzete dovolit zmenu a nemuzete vyhodit cele zarizeni. Blbe se treba vyhazuje radar na lodi a nebo ovladani svetel na letisti. :-) -- tam to chapu, ale stale nechapu vase vzdechy po plne ISA, kdyz rikam, ze v embedded x86-s jeste neuvidime dlouhe roky...
Pane kutil0017e, prosim prectete si neco z historie Unixu, narazite tam potom i na Berkeley a vyvoj na teto univerzite a budete vedet, ze "BSD jsou snad jen varianty Linuxu pod jinou licencí" je nesmysl a ze "a jak BSD ....ideově vychází z UNIXu" je taky nesmysl, protoze BSD je reprezentaci jedne z dvou vetvi Unix vyvoje. Tou druhou vetvi byl AT&T System V. Linux je Unix-like klon, v tom jste se trefil a Android je Linux kernel, zakaznicka C knihovna + google java runtime (vcetne kompilace) a google API/UI/cokoliv...