Intel Publishes "X86-S" Specification For 64-bit Only Architecture

CPU-k, Cooler-ek

https://www.phoronix.com/news/Intel-X86-S-64-bit-Only

hatranya?

  • 1152 megtekintés

( apal v | 2023. 05. 20., szo – 14:30 )

Mi lesz igy a virtualizacioval egy 32-bites guest eseten? 

Emuláció kell, érdekesbb pl Windows alatt a még ki nem gyomlált WoW64 könyvtár és a még azt használó programok. De tudtommal Itanium esetén is emuláció volt, míg AMD64-nél csak üzemmód váltás, ami most kiesik.

Színes vászon, színes vászon, fúj!

Kérem a Fiátot..

( bennyh | 2023. 05. 20., szo – 14:38 )

Én meg arra lennék kíváncsi, kibacás-e ez az AMD-vel (van-e benne valami ami a keresztlicenc megállapodást fel tudja rúgni), vagy csak egyszerűsíteni szeretnék a hw-t és a firmware-t.

Színes vászon, színes vászon, fúj!

Kérem a Fiátot..

Semmi mert jelenleg nagyon nem eszik olyan forrón a kását, sőt...  Tetszőleges CPU család sokéves tervezésen, és teszten megy át mielőtt piacra kerül. Ha nagyon igyekeznek, akkor 2025-26 körül van esélyük kihozni egy ilyen procit. A másik történet, hogy a jelenlegi trend szerint igen erős az AMD térnyerése, és senkit se fog egy "szép" full 64bit történet érdekelni csak úgy.

Halkan jegyzem meg, hogy a mostani X86-64, vagyis AMD64, azaz első K8-as Opteron generációval jött. Akkoriban is nagyon kapkodta a levegőt az Intel, de akkor a Core széria behozásával tudtak fordítani. Lehet szerencséjük volt, mert a notebook vonalhoz tervezett történet jobban bejött, mint a Netburst.

A fullos 64 bit egyébként szoftver oldalról nem annyira vészes mint gondoljuk, mert az elmúlt pár évben gyakorlatilag már minden 64 bites. Ami ragaszkodik a 32-höz vagy régi, vagy hát szóval mondjuk úgy speciális.

Az egyik gyanúm, hogy ez először Xeon-okba fog megérkezni, valószínűleg leghamarabb hyperscaler cloud szolgáltatókhoz. Ott már nagyon sok workload X86-64-only most is. (Értsd: nincs runtime visszaváltás sem) Ráadásul egy hyperscaler-nek nem okoz problémát, ha a - sokszor amúgy is saját fejlesztésű - hypervisor-ba bele kell nyúlni, hogy a bootstrap részből kiirtsák a 32-bites részeket. Managed "PaaS" service-eket, amiket amúgy is teljesen a szolgáltató üzemeltet, simán át tudják tenni rá, anélkül hogy ügyfél bármit észrevenne.

A másik lehetőség, hogy desktopra érkezhet úgy, hogy a heterogén Intel-féle little-big megoldásban csak az egyikfajta (mondjuk a performance) mag lesz X86-S, a másik mag megmarad visszafele kompatibilisnek. Lényegében most is ezt csinálják az AVX512-vel - bár elsőre nem sült el túl jól, főleg a windows support hiányosságai miatt. De gondolom azóta azért jobban kikupálták a magonként eltérő feature set támogatást. Itt elég sokminden a Microsoft hozzáállásán múlik, ha megoldják az emulációt a legacy alkalmazásokhoz, akkor az Intelék sem fognak ilyen átmeneti megoldásokat bevezetni. Vagy - modern Microsoft stílusban - vaskézzel úgy döntenek, hogy a következő negyedévtől minden windows-on push update-tel letiltják a 32-bites binárisok futtatási lehetőségét... :)

Régóta vágyok én, az androidok mezonkincsére már!

Technikailag Linuxon is tudhatsz futtatni 32-bites binarist 64-bites kernelen, mas kerdes, hogy mar az evet sem tudom, mikor volt dolgom utoljara olyannal, hogy amd64-es linuxon i386/i686-os libeket is fel kellett raknom valamiert.

A neccesebb a bootolas, AFAIK (de lehet, hogy outdated az ismeretem) a bootloader meg jar egy kicsit 32-bites uzemmodban, illetve muszajbol hasznalja a szegmens alapu memoriakezelest. Emiatt lehet, hogy kell valamit valtoztatni linuxokon is, hogy mukodjon.

Régóta vágyok én, az androidok mezonkincsére már!

A nagy felhősök éppen Epyc felé mennek jelentős részben, mert a 96 mag per socket olyan sűrűséget ad, és magonként roppant kedvező hőleadást, hogy az intel a fasorban sincs. A Cloudflare-esek vonatkozó blogposztja roppant tanulságos, és az még csak a 7003-as Epyc széria volt. Ha kihoznak egy relatív új architektúrát, akkor kell hozzá fordító, kell egy rakás teszt, hogy valóban rendesen lefordul-e a kód arra, esatöbbi. Egyébként hiába lehet esetleg klasszis megoldás, hogy ha pénzügyileg nem éri meg rá váltani.

Felhőfronton a másik óriási problémája az intel az ARM-os vonal. Több felhős látszik, hogy a saját, sőt ügyfélinfrában is komolyan megjelent (AWS Graviton), illetve az Altera vonallal. Az Altera procihoz pont pár napja jött szembe Supermicroéktól sima egyszerű alaplap: https://www.supermicro.com/en/products/motherboard/r12spd-a

Kezd olyan lenni, hogy minek vegyek intel64bitet (tudom az Itanium volt intel64), hiszen ott az ARM 64bit, ott az Epyc, amivel még visszafelé X86 kompátibilis is vagyok. Azon sem lepődnék meg, hogy ha újra jönnének Apple szerverek az ARM procijukon felbuzdulva.

A kerdes valoban az, hogy mennyi valos elonye lesz fogyasztas, ill. teljesitmenyben. Lehet, hogy ez csak az Intelnek egy maintenance burden csokkentes, akkor valoban nem eselyes, hogy atallnak ra. De persze lehet, hogy nagyot javit teljesitmenyben (szemely szerint nem tartom valoszinunek, de ki tudja :) ).

En pont azert gondolom, hogy az Intel a hyperscaler-eket azert celozhatja meg, mert az ARM bevezetessel mar latszik, hogy vegig tudnak vinni egy ilyen szintu valtast. Amugy vannak bizonyos belso infoim az Amazon Graviton bevezeteserol es valojaban messze nem halad olyan gyorsan, mint azt a cikkekbol es a korulotte levo hype-bol az ember gondolna.

Régóta vágyok én, az androidok mezonkincsére már!

Árulni árulják az instance-okat, és valszin néhány élenjáró fejlesztő csapaton kívül, vagy ahol a mennyiség miatt nincs sokezer USD-s megtakarítás, nem foglalkoznak vele. Ugyanebbe a problémába eshet bele az új intel arch, és az hogy fogyasztás téren tudnak-e valami nagyot dobni, az egyáltalán nem látszik.

En tortenetesen olyan helyen dolgozom, ahol nem sokezer USD-s megtakaritas lett volna, hanem tobb. Az AWS-nek akkora ugyfelei vagyunk, hogy mar beszeloviszonyban vannak velunk. Az Amazonos customer team kerte, hogy ne csinaljuk tomegesen az ARM-ra migralast, mert nincs eleg szabad vasuk hozza... inkabb egyeztessunk rendszresen az utemtervrol. Es bar nagy ugyfelnek szamitunk, azert messze nem a legnagyobb ugyfeleik vagyunk...

Hogy azert nincs eleg ARM-os szerveruk, mert azt gondoltak, hogy kevesen fogjak hasznalni es elore nem rendeltek eleget; vagy egyszeruen nem tudnak eleget gyartatni; azt nyilvan nem mondtak.

Régóta vágyok én, az androidok mezonkincsére már!

Ami ragaszkodik a 32-höz vagy régi, vagy hát szóval mondjuk úgy speciális.

A játékok nagy része nem 32 bites már?

Nem néztem a helyzetre mostanában, de mondjuk olyan 5 éve a Steam és a steames játékok miatt kellett pl. 32 bites alrendszert is telepíteni a 64 bites linuxra.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

( Raynes v | 2023. 05. 20., szo – 21:05 )

Szerkesztve: 2023. 05. 21., v – 15:25

Van ennek előnye és hátránya is. Előnye kétségtelen, hogy kivágják a legacy szemetet, ez egy hosszabb folyamat része, pl. Intel Core i 4. gentől az A20 vonalat sem lehet kapcsolgatni pl. DOS-os memory manager-ek alatt, 12. gentől dobták a CSM/Legacy BIOS támogatást (így csak UEFI és EUFI boot érhető el), néhány laptopban meg alaplapon már SATA sincs, nem hogy IDE, csak NVMe. Így legacy OS-ek már be sem bootolhatók, de ahol még futnak, ott is hiába, mert pl. driverek már nincsenek hozzájuk.

Így majd a 32 bites releváns kódokat újra kell írni vagy újrafordítani 64 biten. Amelyik meg zárt kódú, 32 bit only szutyok, arra emuláció, ezeknek a régebbi kódoknak az az emulációs overhead nem annyira számít. Bár néhány nagyobb legacy appnál, régi játéknál azért számíthat. Nem lenne bajom a 32 bittel, tőlem elférne, de irtani kell, mert sok lusta fejlesztő és upgrade-eléshez lusta user rajta ragad, nem írják át a kódot, nem váltanak 64 bitesre, mert a régi még megy. Ezt a lustaságot lehet elvágni ezzel a kényszerrel, különben ezzel is az lesz, mint az IPv6-tal, hogy nem terjed, mert mindenki a régit használja.

Már azt is helyeseltem, hogy a Win11-gyel a MS is átment 64 bit only-ba, évekkel előtte már a legtöbb nagyobb mainstream disztró is dobta a 32 bites iso-t és csomagokat, a multilib kivételével. Az Apple és az ARM is kiirtotta a 32 bitet egy jó ideje. 64 bites asztali x86 pricik már 20 éve elérhetőek, és már kb. 15 éve megfizethetőek. Teljesen felesleges a lustáknak több átállási haladékot hagyni. Bár gyaníthatóan az AMD ebből profitál, mert ők tovább támogatni szokták a legacy dolgokat.

Ezzel nem csak a 64 bit rendesen használva és kihasználva, optimálisabbá téve, de pl. nem kell olyan legacy problémákkal küzdeni, mint a 32 bites előjeles Unix time, 32 bites memóriakorlát és PAE, fájlrendszerkorlátok, és hasonlók.

Szerk.: amit még meg lehetne fontolni, az az x86 teljes kidobása. Mert ha jól olvasom, kidobják belőle, ami az x86-ot x86-tá tette, és egyfajta AMD64 rész maradna csak meg lényegében. Ilyen durva váltásnál úgyis annyi régi szoftver lesz inkompatibilis, hogy akkor már lehetne egy teljesen új, újragondolt, RISC architektúra, aminek semmi köze nincs az x86-hoz és az AMD64-hez, és a modern kor követelményei szerint van felépítve, a bootolás, virtualizáció, illetve megoldani, hogy egyáltalán ne legyenek benne ilyen Spectre, Meltdown, stb. és ahhoz hasonló hardveres sérülékenységek. Ha már lúd, legyen kövér alapon. Még jobb lenne, ha maga az architektúra nyílt lenne, nem az Intel, hanem az iparág dolgozná ki, és nyílt, licencmentes, hogy többen beszálljanak a gyártásba, nagyobb legyen a verseny, ne csak a két nagy (Intel, AMD) versenyezzen, hanem lényegében minden nagyobb cég, aki komolyan gyárt, gyártat, hozzon ki kompatibilis terméket, és nyomják le egymás árait.

Szerk. 2.: amit még ki lehetne a procikból dobni, az a gusztustalan Intel Management Engine (ME) és AMD Platform Security Processor (PSP) kémprogram Minix-alapokon. Értelmetlen tranzisztorpocsékolás ez is, ahogy az összes többi secured/trusted platform baromság is. Ha már a szutykok kiszántásáról beszélünk, ne végezzenek félmunkát.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Amúgy, tekintve, hogy eredetileg az egész SMM egy ocsmány hack volt arra, hogy kispóroljanak egy mikrokontrollert a gépből... manapság meg már számát sem tudod, hány ilyen embedded controller van a fő processzor mellett itt-ott elszórva a gépben. Teljesen okafogyott lett az SMM, simán be lehetne tenni az ott megvalósított funkcionalitást valamelyik meglevő embedded processzorba.

Régóta vágyok én, az androidok mezonkincsére már!

Szerintem kb ott tartunk, hogy legalabb 4-5 lehetoseg van implementalni ugyanazt a funkcionalitast (tipikusan SMI-re reagalva valami chipset regisztereket piszkalni):

- SMM
- ACPI
- UEFI kernel (ring -1 vagy ring -2, vagy valami ilyesmi)
- valamilyen ME-szeru beagyazott CPU-n futo firmware
- oprendszer kernel (nativ driverrel, nem ACPI interpreterrel)

Régóta vágyok én, az androidok mezonkincsére már!

UEFI kernelben nem igazán van lehetőséged erre, ugyanis amint az OS átveszi az irányítást, akkor marad az ACPI.
Az ME sem erre való, hiszen nem tudja, hogy mit akar a user.

Az ACPI meg pont arra jó, hogy ne kelljen minden operációs rendszernek minden egyes hardverre külön driver, ott az ACPI és kész.

Ok utanaolvastam, annyiban igazat adok, hogy ugy tunik az UEFI Runtime Service-ek nem tudnak onalloan interruptot elfogni az oprendszer elol. Elvileg az OS kernelnek kell visszahivnia bele.

Az ME es ezzel ekvivalens dolgok viszont kb barmit meg tudnak csinalni, ha a vendor ugy dont, hogy ott implementalja az adott funkcionalitast. Nem kell, hogy tudja, hogy mit akar a user, ra tudnak ulni tetszoleges hardver event-re, van hozzaferes I2C buszokhoz, low level power managementhez stb.

Régóta vágyok én, az androidok mezonkincsére már!

Az SMM olyan módban megy, amit beállít magának. Ugyanis előtte elmenti a CPU teljes állapotát, majd visszaállítja azt. A kettő között, amíg az SMM fut, ő maga mondja meg, milyen állapotban legyen a CPU. Hát mostantól nem Unreal állapotban lesz.

De amióta van ACPI, ez az egész SMM igazából irreleváns, ki is vezethetnék azt a megszakítást, ami lehetővé teszi a firmware-eknek az SMM-be jutást.