TÖRETLENÜL FEJLŐDIK AZ INTEL EGYSZERŰSÍTETT X86-OS ARCHITEKTÚRÁJA, AZ X86S – ITT AZ 1.2-ES VERZIÓ

Az X86S architektúra szépen fejlődik, az viszont még mindig kérdéses, hogyan viszonyul hozzá az iparág többi szereplője, például az AMD és a Microsoft.
Víg Ferenc (J.o.k.e.r)
Víg Ferenc (J.o.k.e.r)
2024. szept. 27. 7:52
Töretlenül fejlődik az Intel egyszerűsített X86-os architektúrája, az X86S – Itt az 1.2-es verzió

Az Intel fejlesztőcsapata még tavaly kezdte el az X86-os architektúra egyszerűsítését, amelynek célja, hogy az elavult és szükségtelen technológiákat kigyomlálják, ezáltal kompaktabb, modernebb környezetet tudnak teremteni, plusz ezzel számos újításnak is „helyet teremtenek” majd, igaz, ezekről egyelőre még nem esett szó.

Az X86-os architektúrát az 1970-es évek óta fejlesztik, mind az Intel, mind pedig az AMD sok mindent adott hozzá, köztük számos olyan funkciót és támogatást is, amelyek a mai modern környezetben már nem feltétlenül relevánsak. Azt persze hozzá kell tenni, hogy az X86 egyik előnye mindig is a visszamenőleges támogatás biztosítása volt, ez most a jelek szerint csorbát szenved.

Galéria megnyitása

Az X86S architektúra jelenleg éppen az 1.2-es revíziónál tart, a háttérben folyamatosan zajlik a fejlesztése, így már részeredmények is vannak. A 16-bites és a 32-bites operációs rendszerek támogatása kikerül a repertoárból,  mind védett, mind valós, mind pedig virtuális 8086-os mód esetén. A 64-bites operációs rendszerek alatt nem lesz mód 32-bites rendszerkód futtatására, ami a Ring 0 területét érinti, a Ring 3 esetén azonban megmarad a kompatibilitás, vagyis a 64-bites operációs rendszerek alatt továbbra is használhatóak maradnak a 32-bites alkalmazások.

Utóbbiak, vagyis a 32-bites alkalmazások egyre kevésbé relevánsak manapság, hiszen egyre inkább a 64-bites szoftverek felé tolódik el az iparág, igaz, sok esetben lehet még szükség régi alkalmazások futtatására, amelyek jellemzően 32-bitesek. Ezek a kompatibilitási módon keresztül továbbra is működhetnek, hiszen a felhasználói térből nem vezetik ki a 32-bites alkalmazások támogatását, csak a rendszerkódok esetében szűnik meg a funkció. Operációs rendszerek terén a váltás már igazából megtörtént, a Windows 10 esetében lassan eltűntek a 32-bites kiadások, a Windows 11 pedig már csak 64-bites verzióban jelent meg.

Galéria megnyitása

Az X86S egy érdekes kezdeményezés, amit az Intel indított el, és gyakorlatilag a fejlesztését is a vállalat saját csapata végzi. Arról egyelőre nincs hír, hogy az X86S bevezetéséhez mit szólnak az AMD-nél, egyáltalán terveik-e az architektúra támogatását, mint ahogy az is kérdés, hogy a Microsoft részéről mi az álláspont az újítással kapcsolatban. Az AMD jelenleg az X86-64 architektúrára koncentrál, az X86S-sel kapcsolatban hivatalos nyilatkozat még nem érkezett a cégtől, így egyelőre kérdéses, hogy jónak találják-e az Intel kezdeményezését, vagy sem.

Amennyiben nem sikerül iparági egyetértést kialakítani az X86S körül, az könnyen eredményezheti majd azt, hogy az X86S projekt hamvában holt próbálkozás marad – lényegében az Itanium sorsára juthat, amelynek támogatása tavaly szűnt meg a Linux kernel esetében.

Az X86S architektúrával kapcsolatban rendelkezésre álló részletes hivatalos dokumentum innen tölthető le, természetesen PDF formátumban.

Hírlevél feliratkozás
A feliratkozással elfogadom a Felhasználási feltételeket és az Adatvédelmi nyilatkozatot.

3 hozzászólás

A komment írásához előbb jelentkezz be!
gabushi
gabushi
2024. szept. 27. 22:09
#1

Nem hinném, hogy az AMD ellenezné, bár lépéshátrányt jelentene nekik.

Viszont szükségszerű a "gyomlálás", mert sok tranzisztort lehet ezzel megspórolni (ha nagyon muszáj, lehet csinálni egy emulációs réteget a "régi kódoknak" UEFI szinten.. bár nem valószínű, hogy megtennék).

ARM is azért olyan hatékony amilyen, mert úgy 5-8 évente gyakorlatilag "kukázzák" a teljes kompatibilitást a korábbi vonalaikkal, ezzel hatékonyabb maradhat a core maga.

Erre x86 esetében nagyon szükség lenne, ha ezt jól teszik meg, akkor sokkal kisebb fogyasztási keretű környezetekben is sokkal versenyképesebbé válhat az architektúra.

CaptainSpock
CaptainSpock
2024. szept. 28. 22:06

@gabushi Annyira nagy spórolást nem jelent a 16 és 32 bites támogatás kukázása tranzisztorszámban. Ezek a frontend részt terhelik feleslegesen. De ha a 32 bit marad user mode-ban, akkor igazából a 32 biten egyáltalán nem spórolnak. És amit összesen spórolnak, az a CPU teljes bonyolultságához képest elenyésző. Pl egy vektor egység vagy az egész Out-of-Order végrehajtás miatti komplexitás az ami meredeken zabálja a tranzisztorokat.

Ahol ez valószínűleg sokat segít, az az, hogy a frontendben a kisebb komplexitás, rövidebb logikai útvonalak (egymás utáni tranzisztorok száma) lehetővé teszi a gyorsabb, hatékonyabb, több utasítást egyszerre dekódolni képes frontend tervezését. És ezen a téren a RISC processzorok (ARM, RISC V, POWER stb) messze jobbak (egyszerűbb áramkörök).

Meg hát minek építsenek be olyan dolgokat, amit már szinte senki se használ? És ha valakinek mégis kell a 16 bites mód, akkor egyrészt még sokáig elérhetőek lesznek régi gépek, másrészt meg lehet emulátort használni. Azokat a programokat úgyis jóval lassabb gépre írták.

Valójában a 16 bites módokat már 15-20 éve kukázni kellett volna. Egy kis előre tervezéssel csinálhatták volna azt, hogy amikor elterjed egy új üzemmód (16, 32, 64 bit), akkor bejelentik a régi kivezetését tervezett módon. Pl. hogy még 10 évig támogatják és vége. Így már rég nem lenne 16 bites mód, vagy azt az OS emulálná a nagyon régi programok számára.

Vissza az oldal tetejére