X86-S - kizárólag 64 bites architektúra specifikációját publikálta az Intel

Címkék

X86-S (feltehetően X86-Simplified) néven publikálta az Intel az új, kizárólag 64 bites architektúra specifikációját:

Since its introduction over 20 years ago, the Intel® 64 architecture became the dominant operating mode. As an example of this evolution, Microsoft stopped shipping the 32-bit version of their Windows 11 operating system. Intel firmware no longer supports non UEFI64 operating systems natively. 64-bit operating systems are the de facto standard today. They retain the ability to run 32-bit applications but have stopped supporting 16-bit applications natively.

With this evolution, Intel believes there are opportunities for simplification in our hardware and software ecosystem.

Certain legacy modes have little utility in modern operating systems besides bootstrapping the CPU into the 64-bit mode. It is worth asking the question, “Could these seldom used elements of the architecture be removed to simplify a 64-bit mode-only architecture?”

X86-S is a legacy-reduced-OS ISA that removes outdated execution modes and operating system ISA.

Részletek itt, PDF itt. HUP fórumtopik itt.

Hozzászólások

Ki akarjak irtani az x86 egyetlen elonyet az ARM CPU-khoz kepesf? Hat jo...

I hate myself, because I'm not open-source.

Sokaknak boki a csoret a 90-es evekben irt szoftverek hasznalhatosaga, es kinosan sokan kezdenek kinosan sokat tenni azert, hogy egyre nehezebb legyen futtatni oket.

Sokaig nekem ez veletlen mellekhatasnak tunt.

De a subscription modellel meg az uzleti erdek mogotte is kikovetkeztetheto.

Nehogy mar ingyen jatsz egy 90-es evekben vasarolt vagy konnyen lemasolt kis gepigenyu szoftverrel, igenis fizessel elo es fogadd el azt a T&C-t, amibol tobb penzuk lesz. Es ujra is rajzoljuk, hogy a hardver gyartok is jol jarjanak, cserebe ok is segitsenek nekunk. Szamukra ez tiszta uzleti szimbiozis.

Nalunk nagy valtozas nem lesz: majd qemu-zunk. :)

Hat abbol kiindulva, ahogy a macOS csinalta:

Majd 4 dolgot is at kell allitani, hogy ez a 32 bites x86 emulacio mukodjon, mert "nem biztonsagos". Es ket restart is kell majd hozza, vagy az egyik settinget safe mode-ban kell majd settelni.

macOS-en asszem 11.0 ota vagy az azelotti verzio ota Intelesen pont a wine-hoz kell ezt a pavatancot eljarni. Ami elotte verziokon csak siman mukodott es kesz.

> Majd 4 dolgot is at kell allitani, hogy ez a 32 bites x86 emulacio mukodjon, mert "nem biztonsagos". Es ket restart is kell majd hozza, vagy az egyik settinget safe mode-ban kell majd settelni.

Ezek mind olyan dolgok, amit egy produktív alkalmazás esetén a céges imidzsben vagy konfigurációmenedzsmenttel meg lehet oldani. Az otthoni usernél pedig ha valaki ilyet használ, akkor lesz annyira hozzáértő, hogy meg tudja csinálni, cserében a nagy többség számára biztonságosabb meg könnyebben karbantartható lesz minden más. 

Ez az elmelet.

Valosag: kovetkezo update-nel visszallitanak a 4 kapcsolobol random 2-t es ujra restart - nagy cegnel meg tomegevel nyilnak a ticketek mert erre meg permission sincs. Ez a gyakorlat.

Levezethetoen biztonsagos, mert a legtobb user csak 64 bites "modern" binary-khez fer hozza. De aki masra hasznalna a rendszert, az idegesebb lesz, mintha ReactOS-t hasznalna.

Valahogy az is elkezdodott, hogy csak jailbreakelt iPhone-ra lehetett pl. Nintendo emulatort tenni. Csak akkoriban ezt meg nem fogtak arra, hogy "security", siman csak felvallaltak, hogy kapja be a user es kesz, emulatorozzon mas mobil OS-en.

Windows 12 ilyen procikhoz tartalmazna egy x86-32 emulátort.

Kiindulva abbol hogy anno a 16-bit/dos emulaciot se sikerult megirni 64-bites windowsora (valami ami wine-on siman mukodik), nem varnek csodat toluk.

Vagy teljes mellszélességgel azt mondja, hogy ők is elég időt adtak, tessék mindenből 64 bitest használni.

Sokra megyek vele olyan szoftver/jateknal, ahol a gyarto se letezik mar legalabb 10 eve. Minden masra meg ugyis van open source alternativam linuxra, az meg mukodik arm-on vagy ppc-n vagy akarmin is.

I hate myself, because I'm not open-source.

Virtualizálva ezek továbbra is működni fognak.

Pont az a kerdes hogy oke, oke, virtualizalva, de hogyan. Nyilvan barmilyen arch-on tudok emulalni barmit (kedvencem amikor atmega1284p-re irtak ARM interpretert ami linuxot futtatott) de ha nincs ISA szinten, hw-esen tamogatva akkor ez elegge unhatekony lesz... 

elegge unhatekony lesz... 

Kb 90-es evek vege, 2000-s evek nagyon eleje az amit most lehet megbizhatoan realtime emulalni mai vasakon (pl. pcem-mel), es tekintve hogy mostanaban inkabb a magok szama novekszik mint a single thread teljesitmeny, nem hiszem hogy a kozeljovoben ez nagyon javulni fog, es azert a 64 bites appok ennel joval kesobb kezdtek elterjedni.

I hate myself, because I'm not open-source.

Ha ez a cél, akkor én üzemeltetőként kifejezetten örülök. Ugyanis felőlem nézve óriási szívás ezeket a kövületeket futtatni, ráadásul úgy, hogy megbízható legyen, mert üzlet épül rá. Rég nincs sehol a fejlesztő, a forráskód, senki sem ért hozzá mélyebben, stb., csak görgetjük ezeket (amennyiben kibírja a HW cserét, mert nem olyan a védelme), vagy futtatjuk a 20 éves hardveren abban reménykedve, hogy az örökké működőképes marad.

Nem a 64bit-only miatt kellett volna már rég kidobni a 90-es években meg a 2000-es évek elején született és azóta nem aktualizált szoftvereket, hanem pont ugyan azért amiért az akkor készült számítógépek, autók, stb. is a kukában vannak már azóta. A fenntarthatatlanságuk miatt.

Nem érted. Itt nem szoftverek kidobásáról van szó.
Termelő gépekről, amik köszönik, de jól működnek 30-40 éve, a DOS-os vezérlő PC-jükkel és TUI szoftverükkel.
Szerintem ez lenne a normális, hogy hosszú életciklusú dolgokat csinálunk. Nincs mit ,,aktualizálni": pontosan arra akarjuk használni most is a gépet/szoftvert, amire eredetileg.
Ez a beteges, hogy mondva csinált indokokkal igyekeznek leváltani dolgokat, úgy, hogy az ,,újabb" megoldás ráadásul (nem ritkán) szarabb vagy rugalmatlanabb, mint az eredeti volt.

30 éves x86 szoftverek elég jól futnak teljes hardveremuláció mellett a mai gépeken. Dosbox, vagy ha csak emulált hardver kell Bochs, mellettük van sok egyéb megoldás is. Egy ARM számítógépen is jól működnek. Problémát inkább az újabb x86 szoftverek jelentik. 

A másik probléma az, hogy pont ARM felé ma csak a 32-bites x86 jelenti a hidat. Az Intel kemény perrel fenyegette meg a Qualcommot x86 emulátoros ambíciói miatt. A poén, hogy közben a Microsoft szép csendesen megcsinálta, de csak 32-bitre és nem is terveznek AMD64 változatot. Az AMD64 újabb és a körülötte emelt szabadalmi bástyákból sok még ma sem járt le. 

Olyan opensource emulátorok mint a https://github.com/ptitSeb/box86 is igénylik a 32-bitet ARM-on, érdekesség. https://github.com/AndreRH/hangover is ígéretes opensource cucc, de még van hova fejlődnie. 

Szóval ahhoz, hogy legyen némi átjárhatóság PC és ARM között szükség van továbbra is x86 (32-bites) szoftverekre, ahhoz pedig meg kell maradnia az x86-nak PC platformon. 

Az Intel egyébként tervezgeti, amíg az AMD ezt már egy évtizede meglépte Jaguar alapú APU-jaival PS4 és Xbox One alapjaként. Az csak AMD64-et támogat, ami konzolon nem is probléma. Utód PS5 és Xbox S|x is csak AMD64 módot tud. Ott kell az ilyen ötleteket megvalósítani ahova valók és nem ott ahova nem valók. 

“Az ellenség keze betette a lábát”

Szerkesztve: 2023. 05. 22., h – 06:36

Itanium 2? mondjuk csak a 16 bites programok futtatását dobják :D

"Intel® 64 architecture" már nem mintha mindenhol AMD64-ként szerepelne, de biztos így van. :D

Amennyire én emlékszem az Intel szakítani akart a 32-bittel és kihozott egy kizárólag 64-bites professzort. Az AMD meg meglátta a piaci rést és kihozott egy 32/64-bites professzort (ez volt az Opteron) és letarolta a piacot, ez lett az AMD64.

Mire az Intelnek feltünt hogy nem fogynak sem a 32, sem a 64 bites processzorai kellö ütemben már késö volt, megpróbálták behozni a hátrányt, sokáig nem sikerült.

A "közös megnevezés" pedig az x86_64 (x86-64), ez takarja mind az AMD64-et, mind az Intel 32/64-bites verzióját.

x86-ot nem kellett licencelnie az AMD-nek, mert az nyílt volt és ingyenes minden amerikai cpu gyártó számára. Az x86 kiterjesztések mint MMX, majd SSE voltak licenckötelesek az AMD számára. Egy ideig az AMD csak az MMX-et licencelte az Inteltől és SSE helyett saját 3Dnow megoldását használta. Később az SSE-t és további kiterjesztéseit is licencelte az AMD.

“Az ellenség keze betette a lábát”

Az AMD licenc alapján gyártott 8086-ot és 286-ot is.

Majd a 386-ot megszülte saját kútfőből, amire az Intel pert akasztott a nyakába. Ám a bíróságon már nem állt meg. Úgy tudom hogy a licenc mintha azt tartalmazta volna, hogy 8086 és utódai.

Az volt a kérdés, hogy a 386 a 8086 vagy a 286 utódának tekinthető-e. A bíróság akkor úgy döntött, hogy igen.

De ennél a valóságban valószínűleg bonyolultabb volt a történet.

Igazad van. Az IBM feltétele volt, hogy licencelnie kell az Intelnek konkurens gyártók számára x86-ot mert több forrást akart cpu-ból is. Az IBM nem akart függővé válni az Inteltől. Az akkor sokkal erősebb IBM feltételeibe pedig saját érdekében belement az Intel. 386-nál pedig valóban elvesztette a pert az Intel az AMD-vel szemben, akik reverse engineering fejtették vissza az Intel 386-osát a bírósági ítélet szerint akkor legálisan az AMD meglevő 286 licencével. Így folytatódott a kompatibilis processzorok gyártása 486-ig. A kisebb Cyrix is élvezte az AMD által kitaposott utat. A superscalar Pentium 1-et branch prediction technológiájával már jogilag jól bevédte az Intel, neve is levédett márkanév volt. AMD első válasza 5x86 egy feljavított 486 volt, 133 Mhzen hozta a Pentium 75 teljesítményét, túlhajtva 160 Mzhre pedig Pentium 90-ét és 486 alaplapokba illeszkedett. Az AMD második válasza 5k86, más néven AMD K5 már Pentium alaplapokkal működött, socket 5 és socket 7 változatokkal. Ez az AMD korábbi Am29000 risc architektúrára épült. Nem volt rossz tervezés de teljesítményben csak a Cyrix 6x86-ot múlta felül az aktuális Intel Pentiumokat már nem. Talán az akkori AMD legjobb döntése volt, hogy felvásárolta a NexGen fab nélküli CPU céget, akik integer teljesítményben elérték a korabeli Pentiumokat. Ők is RISC magot és x86 utasításfordítás technológiát használtak viszont lebegőpontos egységük nem volt. Ez a NexGen RISC86 lett az alapja az AMD K6-nak ami már a harmadik Socket 7 pentium alaplapba illeszkedő processzora volt az AMD-nek. Az AMD K6 már mindenben verte az Intel Pentium 1-et, viszont időközben kijött az Intel Pentium Pro vonaláról továbbfejlesztett és mainstreambe betolt Pentium II újra rávert az AMD-re. Erre az AMD válasza a K6-2 volt, aminek maradnia kellett a socket 7 alaplapokon, mert az Intel időközben a Pentium II slot 1 alaplapjairól kizárta a konkurenciát. Egy kis marketing tuninggal super 7-nek nevezte az AMD a felturbózott késői socket 7 alaplapokat. Remekül teljesített a RISC86 és annak továbbfejlesztett utódai, az AMD versenyben tudott maradni az Intellel nem úgy mint a Cyrix, később VIA. De az Intel vezető pozícióját még sokáig nem tudta elvenni az AMD. A Zen -től kezve viszont már az AMD a jobb pc processzorgyártó. 

“Az ellenség keze betette a lábát”

Nem így volt! Az Intel az Itanium nevű teljesen új architektúrában látta a jövőt. Ezért kapta a neves IA-64 nevet az architektúra. Az Itaniumot, akkor még nagy unix cégek saját archjainak kiszorítására szánta az Intel. Power/PPC, UltraSparc, MIPS, Alpha, HP PA-risc mind ment volna a levesbe. Az Intel partnere a régi unixos HP volt, így az Alpha és PA-risc már HP oldalról be volt áldozva a közös üzletbe. Az x86-tal szemben az Itanium teljesen Intel és HP tulajdon volt, ezzel végleg ki lett volna szorítva az AMD és akkor még létező Cyrix (VIA) a 64-bites jövőből. A meglevő 32 bites világ IA-32 szép lassan elhalványodott volna, a 4GB ram limit szépen lassan beverte volna az utolsó szöget a PC CPU-k koporsójába. Majd jött az AMD megcsinálta az AMD64-et és kezdett forró lenni a talaj az Intel számára, ráadásul az Itanium sem lett kirobbanó siker. Gyorsan csinált az Intel egy saját 64-bites kiterjesztést a PC vonalra, természetesen AMD64 incompatibilisen. Ekkor köpött a Microsoft az Intel 64-bites levesébe azzal, hogy kijelentették nem fognak két különböző 64-bites PC archot támogatni és mivel az AMD volt az első csak az AMD64 lesz támogatva Windowsokon. Inteléknél már úgyis támogatnak egy 64-bites archot, az Itaniummal, kettőt nem fognak. Az Intelnek így licencelnie kellett az AMD64-et, a marketingesek még próbáltak a nevezéktannal kavarni. Az Intel-féle AMD64 így előbb IA-32e (azt a látszatot keltve, hogy ez nem "igazi" 64 bit mint az Itanium) majd lett EM64T, Intel 64, x86_64. Csak ne AMD64 legyen! :-) 
Még próbálkozott az Intel hardveres x86 támogatással az Itaniumnál mivel a korábbi szoftveres megoldással lassabb volt a drága Itanium mint a sokkal olcsóbb csúcs x86 cpuk legacy x86 kódok futtatásánál és igény továbbra is volt erre, de menthetetlen volt.

Végül az Itanium teljesen megbukott és AMD64 lett "A" 64-bites architektúrája a jövőnek hosszú ideig, még be nem jött mellé az ARM64. 

“Az ellenség keze betette a lábát”

csak apró pontosítás:

- Az Intel az Itanium esetén nem később próbálkozott meg a hardveres x86 emulációval, hanem a kezdeti modelleknél (Montecito előtti modelleknél), pont később hagyták ki ezt a funkciót a processzorból, mert a szoftveres emuláció gyorsabb volt (IA-32 EL).

- Az Itanium bukását nem kis részben okozta az, hogy kezdetben nem Intel-HP szövetség volt, hanem Intel-HP-SGI. Az Itanium architektúrában az volt az újdonság, hogy amit az x86 futási idejű predikciót csinál, annak egy jelentős része fordítási időben történik. Ezért viszont az architektúrára optimalizált fordító program tulajdonképpen fontosabb, mint a többi platform esetében - ezt kellett volna megcsinálnia az SGI-nek, de előbb ment csődbe, mint hogy sikerült volna. Emiatt azt, hogy valójában milyen potenciál volt az Itanium platformban, sosem fogjuk megtudni.

Köszi a pontosítást. A probléma szerintem az volt, hogy a királycsináló Sun Microsystems hiányzott a koalícióból. Sőt ahol tudta gyengítette Java csodafegyverével az Itaniumot. Pocsék is volt a Java teljesítménye. 

Azt mondják oroszok eléggé sikeresek ott ahol az Itanium elbukott. Az Elbrus ráadásul valódi VLIW processzor nem "csak" EPIC. A legújabb Elbrus-16S egész jól teljesít annak ellenére, hogy csak 16nm technológián tuják gyártani. Code morphing technológiával tud x86 és AMD64 módot is. Kár, hogy a háború miatt most hosszú ideig nem a technológiai együttműködés útját fogják járni az oroszok velünk. A archi elmélet alapján a VLIW lenne a hatékonyabb megoldás, egyszerűbb hardver komplexebb szoftver, főleg fordító. De a szoftveres oldal utólag is optimalizálható. Illetve a VLIW mentes azoktól a hardveres kódvégrehajtást optimalizáló megoldásoktól, amik az utóbb időkben több biztonsági incidens okozói voltak. 

“Az ellenség keze betette a lábát”

Na végre ismét tisztul az x86, amely fogadjunk hogy ma is tartalmazza még a szegmentált címzés emulálását is (1 MB RAM fölé lehetett címezni 65520 byte-tal).

Viszont akik búslakodnak, ne tegyék:
   1. tervezőasztaltól termékig még évek telnek el
   2. jelenlegi x86 generációt még vagy 10 évig lehet majd újként kapni, sőt lehet hogy marad gyártósoron "legacy ág".
   3. használt PC sokáig lesz a régi cuccok futtatására. Ahogy ma is kapsz 486-ost.
   4. CPU emuláció se halott ügy, hiába vagy ötöde a tempó. Egy eredetileg Pentium IV-en futó alkalmazást nehogy már ne vigyen rendes tempóban egy mainál is gyorsabb CPU.

ARM egyébként szintén bejelentette 2 éve a 64bit-only irányt, kitakarítva a sok múltbeli kompatibilitást.
https://www.arm.com/blogs/blueprint/64-bit

Most itt egyfajta ajánlás jellegű jött. Konkrét cpuról szó  sem volt. Nagyon könnyen lehet, hogy ez whitepaper marad aztán ennyi. Van még esélye az Atomos sorsra jutni, hogy "válámi ván de nem áz igázi".

Ipari felhasználásra bőven lesznek elérhető megoldások, illetve be lehet majd előre vásárolni, hogy ha egyáltalán ez valóban termékes formát ölt.

Én úgy érzem, hogy az irány nem rossz. Ha belegondolsz, kihoznak egy új architektúrát, amiben sok mm2 szilícium felel a régi kompatibilitásáért és le kell tesztelni
  - x86_64 funkcionalitást
  - x86_32 funkcionalitást
  - x86_16 funkcionalitást

Helyette a jövőben egyrészt kimarad az új architektúrából az utóbbi 2 "ilyen kivétel olyan kivétel" áramkörhalmaza, továbbá kimarad az utóbbi kettő alapos tesztelése.
Jelentős költségmegtakarítás ez egy terméknél és ha jól belegondolsz, az utóbbi kettőnek 10 év múlva, amikorra kidőlnek a mostani PC-k, gyakorlatilag semmi jelentősége nem lesz csak felesleges költség a termék előállítása során.

Ezért kezdett az ARM is 64 bit only új fejlesztésekbe, kisöpörve az ARM7TDMI (ARM v4 architektúra) és a többi őskövülettel való kompatibilitást.

Na meg azon alrendszer tesztelésén, amire a tesztkörnyezetet is egyre nehezebb életben tartani (humán oldalról egyre inkább ismeretlenné válik).
Hogy értsd: jöhetnek a szavazatok, aki emlékszik még a szegmens és offset lehetőségére és korlátaira, illetve arra hogy mikor és hogyan használsz a far jump-ot?