[Re:] Négy nagy x86-os újítással készül a jövőre az AMD és az Intel

Legfrissebb anyagok

Mobilarena témák

PROHARDVER! témák

IT café témák

GAMEPOD témák

LOGOUT témák

Új hozzászólás Aktív témák

Pikari veterán

#26
#25 Robitrix
2025-10-22 12:27:52

Új Válasz
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

Pikari

veterán

#25 Robitrix

#25 Robitrix
Az X86-ban ott van azért a visszamenő kompatibilitás kérdése, ami nagyon erős. Ha előszedem a régi pacmant mondjuk 40 évvel ezelötről az utasítás szinten kompatibilis lesz a mai CPU-val. ettől még persze egy dosbox azért kell a dologhoz. de a gépi kódú utasitások ma is futnak a mai CPU-n. Emiatt rengeteg ma már felesleges funkció van a CPU-ban. Ha ma neki állnának tervezni egy új X86-os CPU-t arra koncentrálva, hogy mi kell bele ma egy sokkal ütösebb kevesebb áramkörből felépülő CPU lehetne csak az a fránya 40 éves kompatibilitás. Ma már nem igen akar azért senki mondjuk 8 vagy 16 bites utasításokat végrehajtani. elég volna a 32 vagy 64 bites. Ennek okán a nagyjából 850-900 x86-os utasitás(CISC) felét ki lehetne baszni az utasítás készletből. rögtön egyszerübb lenne a mikrokód. De ma adott a lehetőség, hogy mondjuk 8-16 bites adatokat töltsek be mondjuk a memóriából az akkumulátor regiszterbe. minden matamatikai utasításnak meg van az utasítás készletben a 8/16/32/64 bites verziója. ezért is és a közben kitalált új funkciók miatt lett az eredeti 60-70 féle X86-os utasítás készlet mára 900 körüli cisc utasításra. (a pontos számot nem tudom) Persze még simán futnak malörökbe. Ilyan volt a Warzone például 2020 tavaszám. kiadták a programot. aztán hamar kiderült, hogy úgy elszáll a program, mint a győzelmi zászló. Legalább is az AMD A4 talán A6 oricikin is, amit még rengetegen használtak. Amelyeknek a mag száma és teljesítménye böven elég lett volna már a játékhoz. Kiderül valahol az AMD A6-ról A8-ra váltáskor kibövitették a proci utasítás készletét talán az SSE 4-gyel már mig a A4 A6 procik csak a SSE 3 utasítás családik ismerték ki magukat. a lefordított játék kódjába viszont SSE 4-es utasítások kerültek. Amitől a régi procik csak néztek, hogy mi a francot akarnak vele végrehajtatni. ezért gyorsan újra irták a játék kódját hogy ne maradjon benne SSE 4-es utasítás. Mint ahogy volt intel CPU korlátozás is, amin már nem müködött a játék Ami által lasabb lett egy árnyalattal a program, viszont még sok millió procin elérhetővé vált.

Az x86ban nem 900 utasítás van, hanem kb 5000. Az utasítások száma azért tűnik ennél kevesebbnek, mert ha megnézel egy asm dokumentációt, és abban írod a programot, akkor több teljesen eltérő opkódú utasítást is ugyanúgy hívnak. De attól függően, hogy pl milyen paraméterek vannak az utasítás után, sok esetben teljesen más bájtkódra fordul le, amik teljesen máshogy vannak enkódolva. Ez még rendben is lenne, mert csak a dekódert bonyolítanák, de mivel ezeket a processzornak célirányosan más és más részén kell lefuttatni, ha azt akarod, hogy rendes teljesítményt tudj belőlük kicsikarni, akkor masszívan emelkedik tőle a tranzisztorszám mindenhol. Önmagában nem csak az utasítások száma miatt szállt el a tranzisztorszám, hanem azok miatt a tényezők miatt, amiket a korábbi hozzászólásomban leírtam. Ettől függetlenül igaz, amit írsz, hogy ezeknek nemhogy felét, hanem inkább 95%-át ki lehetne dobni, de a fő probléma az, hogy maga az utasításkészlet egy értelmetlen, koncepciótlan, összekuszált katyvasz. Mindenképp az alapoktól kell lecserélni, nem javítható már meg.
Egyébként a programozó teljes inkompetenciája ellen nem véd meg semmi, az már régebben is így volt, 2000 közepén is rendszeresen előfordult, hogy pl az asperger szindrómás bitzsoké nem érti, hogy mi az az utasításkészlet, és pl SSE2-vel fordította le a pentium3makra szánt linux disztribúciót. Most is ugyanez van, és nem érti az ilyen, hogy mi az a -march=x86_64 kapcsoló, mert neki a gyorstalpaló nőgyógyász-szolárisrendszergazda tanfolyamon azt tanították, hogyan kell tábortűz körül énekelgetni, sőt, már azt sem, hanem valami újgenerációs viccnyelvben az életérzés átadása a divat szkriptelgetés közben, ahol egy a=b szintű utasítás kb 200 órajeles overheaddel fut, de ez még a jobbik eset, mert azt legalább nem kell gépi kóddá fordítani, így legalább nem tudja azt a részét a dolognak elrontani. Sajnos ez ellen az ARM, és a risc-v se fog megmenteni senkit, mert ott is utasításbővítmények formájában lesz (vagy nem lesz) hozzácsapva a processzorokhoz mindenféle érdekes simd egység.
Robitrix őstag

#25
#23 Pikari
2025-10-22 11:51:41

Új Válasz
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

Robitrix

őstag

#23 Pikari

#23 Pikari
Fogalmam sincs, hogy a fejedben a risc-v hogy kapcsolódott össze kínával, mivel kínában pont az x86ot/armot/mipset erőltetik. Mindösszesen egyetlen kézzel fogható kínai risc-v alapú kísérleti számítógépről tudok, ami kereskedelmi forgalomban ténylegesen is kapható, méghozzá a bitmain gondozásában. Nekik viszont konkrétan semmi közük nincs a kínai államhoz/hadsereghez, mivel ők inkább a bányászcuccok fejlesztésében járatosak, amit az állambácsi annyira nem nagyon szokott sehol sem különösebben szeretni.
Ha szakmai kérdésekről akarsz beszélgetni, hát legyen, csak akkor viszont nem értem, hogy miért szövöd bele a személyeskedést is a hozzászólásaidba.
Az, hogy a szuperskalár processzorok létrehozásához szükséges több db végrehajtóegység és futószalag létrehozása tranzisztort emészt fel minden arch esetén, az addig rendben is van, azonban elsiklasz afölött, hogy ezeknek a futószalagoknak a bonyolultsága és tranzisztoréhsége masszívan növekedik annak ellenére is, hogy ezek csak mikroutasításokat hajtanak végre. x86nál eleve külön dekóderek vannak a különféle típusú utasítások dekódolására (egyszerű, komplex, floating point, avx, avx512) amik aztán belekerülnek egy közös cachebe, ahonnét egy reorder bufferbe jutnak, ahonnét le lesznek küldve a szuperskalár végrehajtóegységek felé attól függően, hogy az adott végrehajtóegység melyik típusú mikroopkódot tudja végrehajtani (branch egység, sima alu egység, mul-ra optimizált egységek, fmul/fdiv végrehajtására optimizált egységek, memória in/out egységek, sse alu egység, sse shuffle egység, avx egységek) aztán ezek többszörözve, egymás hegyén hátán szarrábonyolítva. Ez csak azért van ennyire megbonyolítva, mert az x86 maga túl van bonyolítva, ha az alap arch értelmes emberi egyedek által van megtervezve, akkor értelemszerűen a szuperskalár egységek is jóval egyszerűbbek lesznek - mivel az x86 utasításkészlet rendkívül bonyolult és terjedelmes, nem megoldható az, hogy nagyon egyszerű szuperskalár egységekkel egy hatékony x86 processzort létrehozz, függetlenül attól, hogy a mikroutasítások maguk végletekig egyszerűsíthetőek, x86on egyszerűen túlságosan beesne a sebesség, ha nem bonyolítod és optimizálod szarrá a végrehajtóegységeket kb hatványos karakterisztika szerint növekedő tranzisztortömegekkel.

Az X86-ban ott van azért a visszamenő kompatibilitás kérdése, ami nagyon erős. Ha előszedem a régi pacmant mondjuk 40 évvel ezelötről az utasítás szinten kompatibilis lesz a mai CPU-val. ettől még persze egy dosbox azért kell a dologhoz. de a gépi kódú utasitások ma is futnak a mai CPU-n. Emiatt rengeteg ma már felesleges funkció van a CPU-ban. Ha ma neki állnának tervezni egy új X86-os CPU-t arra koncentrálva, hogy mi kell bele ma egy sokkal ütösebb kevesebb áramkörből felépülő CPU lehetne csak az a fránya 40 éves kompatibilitás. Ma már nem igen akar azért senki mondjuk 8 vagy 16 bites utasításokat végrehajtani. elég volna a 32 vagy 64 bites. Ennek okán a nagyjából 850-900 x86-os utasitás(CISC) felét ki lehetne baszni az utasítás készletből. rögtön egyszerübb lenne a mikrokód. De ma adott a lehetőség, hogy mondjuk 8-16 bites adatokat töltsek be mondjuk a memóriából az akkumulátor regiszterbe. minden matamatikai utasításnak meg van az utasítás készletben a 8/16/32/64 bites verziója. ezért is és a közben kitalált új funkciók miatt lett az eredeti 60-70 féle X86-os utasítás készlet mára 900 körüli cisc utasításra. (a pontos számot nem tudom) Persze még simán futnak malörökbe. Ilyan volt a Warzone például 2020 tavaszám. kiadták a programot. aztán hamar kiderült, hogy úgy elszáll a program, mint a győzelmi zászló. Legalább is az AMD A4 talán A6 oricikin is, amit még rengetegen használtak. Amelyeknek a mag száma és teljesítménye böven elég lett volna már a játékhoz. Kiderül valahol az AMD A6-ról A8-ra váltáskor kibövitették a proci utasítás készletét talán az SSE 4-gyel már mig a A4 A6 procik csak a SSE 3 utasítás családik ismerték ki magukat. a lefordított játék kódjába viszont SSE 4-es utasítások kerültek. Amitől a régi procik csak néztek, hogy mi a francot akarnak vele végrehajtatni. ezért gyorsan újra irták a játék kódját hogy ne maradjon benne SSE 4-es utasítás. Mint ahogy volt intel CPU korlátozás is, amin már nem müködött a játék Ami által lasabb lett egy árnyalattal a program, viszont még sok millió procin elérhetővé vált.
Robitrix őstag

#24 2025-10-22 11:19:21

Új Válasz
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

Robitrix

őstag

a kompatibilitás miatt egymásra vannak utalva. az nem járható út, hogy annyira eltérő procikat gyártanak, hogy a programok egy része egyig gyártó cuccán fut a másik meg a másikon mint ahogy az se, hogy a programok kát változatban készüljenek. kijön mondjuk a GTA VII (2045-ban talán) aztán volna egy GTA VII AMD és egy GTA VII Intel verzió.... a felhasználók meg mind a két céget elküldené a picsába... Ezért kénytelenek egyeztetni és specifikálni mi lesz a jövő X86 procijaiban. Ha microkód szinten nem is egyforma egy utasítás végrehajtása, de az, hogy mit csinál egy új utasítás vagy utasítás készlet azt bizony össze kell hangolni. Anélkül nem kompatibilis procikat gyártanának. Így hiába üzleti riválisok egymásra vannak utalva.
Pikari veterán

#23
#22 ddekany
2025-10-15 13:33:59

Új Válasz
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

Pikari

veterán

#22 ddekany

#22 ddekany
Nem az utásításkészlet miatt, mivel az összes teljesítmény orientált (nem beágyazott, hanem mondjuk legyen desktop) CPU magra igaz az arány. Mert az összes elterjedt ISA-ban (szóval nem VLIW) sorban vannak utasítások, de sokszor lehetne részben párhuzamosan futtatni őket. Az ősszesben vannak feltételes elágazások, ahol tippre el kell indulnod egy irányba, vagy akár többe. Stb.
A többit meg magyarázhatod, akit érdekel, rád keres, és látja. Ez is mekkora szánalmas érvelés, hogy de hát a RISC-V nyugatról indult, tehát te aztán neeem... Közben napnál világosabb neked te is, hogy történelmileg úgy alakult, hogy a RISC-V a geopolitikai licenc szívózások következtében erősen összeasszociálódott a CCP-vel ("Kínával") és az azt szopdosó netes hadsereggel. De ennyit erről.

Fogalmam sincs, hogy a fejedben a risc-v hogy kapcsolódott össze kínával, mivel kínában pont az x86ot/armot/mipset erőltetik. Mindösszesen egyetlen kézzel fogható kínai risc-v alapú kísérleti számítógépről tudok, ami kereskedelmi forgalomban ténylegesen is kapható, méghozzá a bitmain gondozásában. Nekik viszont konkrétan semmi közük nincs a kínai államhoz/hadsereghez, mivel ők inkább a bányászcuccok fejlesztésében járatosak, amit az állambácsi annyira nem nagyon szokott sehol sem különösebben szeretni.
Ha szakmai kérdésekről akarsz beszélgetni, hát legyen, csak akkor viszont nem értem, hogy miért szövöd bele a személyeskedést is a hozzászólásaidba.
Az, hogy a szuperskalár processzorok létrehozásához szükséges több db végrehajtóegység és futószalag létrehozása tranzisztort emészt fel minden arch esetén, az addig rendben is van, azonban elsiklasz afölött, hogy ezeknek a futószalagoknak a bonyolultsága és tranzisztoréhsége masszívan növekedik annak ellenére is, hogy ezek csak mikroutasításokat hajtanak végre. x86nál eleve külön dekóderek vannak a különféle típusú utasítások dekódolására (egyszerű, komplex, floating point, avx, avx512) amik aztán belekerülnek egy közös cachebe, ahonnét egy reorder bufferbe jutnak, ahonnét le lesznek küldve a szuperskalár végrehajtóegységek felé attól függően, hogy az adott végrehajtóegység melyik típusú mikroopkódot tudja végrehajtani (branch egység, sima alu egység, mul-ra optimizált egységek, fmul/fdiv végrehajtására optimizált egységek, memória in/out egységek, sse alu egység, sse shuffle egység, avx egységek) aztán ezek többszörözve, egymás hegyén hátán szarrábonyolítva. Ez csak azért van ennyire megbonyolítva, mert az x86 maga túl van bonyolítva, ha az alap arch értelmes emberi egyedek által van megtervezve, akkor értelemszerűen a szuperskalár egységek is jóval egyszerűbbek lesznek - mivel az x86 utasításkészlet rendkívül bonyolult és terjedelmes, nem megoldható az, hogy nagyon egyszerű szuperskalár egységekkel egy hatékony x86 processzort létrehozz, függetlenül attól, hogy a mikroutasítások maguk végletekig egyszerűsíthetőek, x86on egyszerűen túlságosan beesne a sebesség, ha nem bonyolítod és optimizálod szarrá a végrehajtóegységeket kb hatványos karakterisztika szerint növekedő tranzisztortömegekkel.
ddekany nagyúr

#22
#21 Pikari
2025-10-15 13:16:44

Új Válasz
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

ddekany

nagyúr

#21 Pikari

#21 Pikari
Na azért tegyük tisztába a dolgokat, az out of order és a spekulatív végrehajtás és "hasonlók" leszervezésére is a túlbonyolított utasításkészlet miatt megy a végtelen mennyiségű tranzisztormennyiség egy mai x86os processzorban.
Ebben semmi politika nem volt, a risc-v-t is ugyanazok az országok alkották meg, amik korábban az x86-ot, szóval erősen olyan dolgokat képzelsz ide, amik nincsenek. A politikai elkötelezettségemről pedig annyit, hogy még szavazni se szoktam elmenni.
Ha te személy szerint nem érted, hogy az x86 utasítások mennyire bonyolult módon működnek, azon nem csodálkozom, de attól még nem én vagyok az elmebeteg

Nem az utásításkészlet miatt, mivel az összes teljesítmény orientált (nem beágyazott, hanem mondjuk legyen desktop) CPU magra igaz az arány. Mert az összes elterjedt ISA-ban (szóval nem VLIW) sorban vannak utasítások, de sokszor lehetne részben párhuzamosan futtatni őket. Az ősszesben vannak feltételes elágazások, ahol tippre el kell indulnod egy irányba, vagy akár többe. Stb.
A többit meg magyarázhatod, akit érdekel, rád keres, és látja. Ez is mekkora szánalmas érvelés, hogy de hát a RISC-V nyugatról indult, tehát te aztán neeem... Közben napnál világosabb neked te is, hogy történelmileg úgy alakult, hogy a RISC-V a geopolitikai licenc szívózások következtében erősen összeasszociálódott a CCP-vel ("Kínával") és az azt szopdosó netes hadsereggel. De ennyit erről.
Pikari veterán

#21
#20 ddekany
2025-10-15 12:55:16

Új Válasz
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

Pikari

veterán

#20 ddekany

#20 ddekany
A cache nélküli die méret 99% megy arra... ekkora égő kamut. Közben tudod jól, hogy az out-of-order meg spekulatív végrehajtás és hasonlók leszervezésére megy a javarésze, ami utasítészlettől független. De a politikai elkötezettséged, ami más topikokból ismert, erre visz. Ez már elmebetegség kategória, komolyan.

Na azért tegyük tisztába a dolgokat, az out of order és a spekulatív végrehajtás és "hasonlók" leszervezésére is a túlbonyolított utasításkészlet miatt megy a végtelen mennyiségű tranzisztormennyiség egy mai x86os processzorban.
Ebben semmi politika nem volt, a risc-v-t is ugyanazok az országok alkották meg, amik korábban az x86-ot, szóval erősen olyan dolgokat képzelsz ide, amik nincsenek. A politikai elkötelezettségemről pedig annyit, hogy még szavazni se szoktam elmenni.
Ha te személy szerint nem érted, hogy az x86 utasítások mennyire bonyolult módon működnek, azon nem csodálkozom, de attól még nem én vagyok az elmebeteg
ddekany nagyúr

#20
#17 Pikari
2025-10-15 12:50:41

Új Válasz
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

ddekany

nagyúr

#17 Pikari

#17 Pikari
Mivel egy mai x86-64-es processzor die méretének (cache memóriát leszámítva) alsó hangon 99%-a egy 40 éve elavult, a szükségesnél több százszorosan túlbonyolított, kezelhetetlen fostenger hardveres emulációjára megy el, az Intel és az AMD minden erejével azon van, hogy kitaláljon valamit, amitől az egész csak fele annyira lesz szar. A valóság viszont az, hogy ez az ISA menthetetlen, már a 386os is csak egy pótcselekvés volt. Hosszú távon hagyni kell az egészet megdögleni, és teljesen szoftveresen emulálni, csak sajnos ezek a megoldások apple/qualcomm/ms részéről nem igazi megoldások, csak egy másik egyedi zárt obskúrus dobozba akarják zárni a felhasználót ahelyett, hogy tényleges alternatívát nyújtanának. Jelenleg az egyetlen lehetséges alternatíva a risc-v, amely szerencsés csillagállás esetén 10 éven belül készen fog állni arra, hog átvegye a stafétát.

A cache nélküli die méret 99% megy arra... ekkora égő kamut. Közben tudod jól, hogy az out-of-order meg spekulatív végrehajtás és hasonlók leszervezésére megy a javarésze, ami utasítészlettől független. De a politikai elkötezettséged, ami más topikokból ismert, erre visz. Ez már elmebetegség kategória, komolyan.
Pikari veterán

#19
#15 Cassi
2025-10-15 12:42:45

Új Válasz
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

Pikari

veterán

#15 Cassi

#15 Cassi
Ocsmány is és mindenképpen több év, mire elterjed, mert vagy külön fordított exe kell hozzá vagy belső elágazás a CPUID alapján, ami még undorítóbb (és mindkét ág külön tesztelendő stb.).

Én annyit mondhatok programozóként - bár manapság egyre ritkábban programozok, és nagyon ritkán teszek közzé futtatható fájlt - hogy x86 tekintetében a kompatibilitást szem előtt tartva kizárólag az első x86-64 (64 bit és sse2 maximum) specifikációra fordítok, és ez a halálom napjáig jó eséllyel így is marad. Ez esetleg abban az esetben változhat, ha valaki gépfegyvert tarkómhoz szögezve arra kényszerít, hogy más kapcsolókat írjak be a gccnek.
ddekany nagyúr

#18
#15 Cassi
2025-10-15 12:37:19

Új Válasz
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

ddekany

nagyúr

#15 Cassi

#15 Cassi
Ocsmány is és mindenképpen több év, mire elterjed, mert vagy külön fordított exe kell hozzá vagy belső elágazás a CPUID alapján, ami még undorítóbb (és mindkét ág külön tesztelendő stb.).

Jó esetben legalább a felhasználó számára ez áttetsző lehet. (Ellenben a 32 VS 64 bittel, ahol a felhasználónak kellett állandóan a kétféle változat közül választania.)
Pikari veterán

#17
#16 S_x96x_S
2025-10-15 12:31:19

Új Válasz
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

Pikari

veterán

#16 S_x96x_S

#16 S_x96x_S
Lehet, hogy az APX nem Kína ellen született
- de Kína nélkül aligha született volna meg.

Mivel egy mai x86-64-es processzor die méretének (cache memóriát leszámítva) alsó hangon 99%-a egy 40 éve elavult, a szükségesnél több százszorosan túlbonyolított, kezelhetetlen fostenger hardveres emulációjára megy el, az Intel és az AMD minden erejével azon van, hogy kitaláljon valamit, amitől az egész csak fele annyira lesz szar. A valóság viszont az, hogy ez az ISA menthetetlen, már a 386os is csak egy pótcselekvés volt. Hosszú távon hagyni kell az egészet megdögleni, és teljesen szoftveresen emulálni, csak sajnos ezek a megoldások apple/qualcomm/ms részéről nem igazi megoldások, csak egy másik egyedi zárt obskúrus dobozba akarják zárni a felhasználót ahelyett, hogy tényleges alternatívát nyújtanának. Jelenleg az egyetlen lehetséges alternatíva a risc-v, amely szerencsés csillagállás esetén 10 éven belül készen fog állni arra, hog átvegye a stafétát.
S_x96x_S veterán

#16
#14 Ajándékok
2025-10-15 12:23:44

Új Válasz
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

S_x96x_S

veterán

#14 Ajándékok

#14 Ajándékok
Nem Kína ellen csinálták?

Lehet, hogy az APX nem Kína ellen született
- de Kína nélkül aligha született volna meg.
Cassi őstag

#15
#12 ddekany
2025-10-15 11:43:54

Új Válasz
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

Cassi

őstag

#12 ddekany

#12 ddekany
Az APX (aminek érkezését még nem ígéri a cikk) radikálisabban tűnik a x86 -> x86-64 átmenetnél is. Pl. 3 operandusos utasítások. Lényegében egy tök új ISA, erős ARM/RISC áthallásokkal. Csak úgy van tervezve, hogy lehessen egy szálon belül keverni x86-64 kóddal. Szóval akiket eddig esztétikailag zavart a legacy támogatás, ezzel szép nagy lapáttal rádobnának az ocsmányságra...

Ocsmány is és mindenképpen több év, mire elterjed, mert vagy külön fordított exe kell hozzá vagy belső elágazás a CPUID alapján, ami még undorítóbb (és mindkét ág külön tesztelendő stb.).
Ajándékok aktív tag

#14
#13 S_x96x_S
2025-10-15 11:20:36

Új Válasz
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

Ajándékok

aktív tag

#13 S_x96x_S

#13 S_x96x_S
> APX ... Lényegében egy tök új ISA,
inkább csak x86-64 ISA bővítése.

Nem Kína ellen csinálták?
S_x96x_S veterán

#13
#12 ddekany
2025-10-15 11:15:24

Új Válasz
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

S_x96x_S

veterán

#12 ddekany

#12 ddekany
Az APX (aminek érkezését még nem ígéri a cikk) radikálisabban tűnik a x86 -> x86-64 átmenetnél is. Pl. 3 operandusos utasítások. Lényegében egy tök új ISA, erős ARM/RISC áthallásokkal. Csak úgy van tervezve, hogy lehessen egy szálon belül keverni x86-64 kóddal. Szóval akiket eddig esztétikailag zavart a legacy támogatás, ezzel szép nagy lapáttal rádobnának az ocsmányságra...

> APX ... Lényegében egy tök új ISA,
inkább csak x86-64 ISA bővítése.
ddekany nagyúr

#12
#11 S_x96x_S
2025-10-15 10:33:31

Új Válasz
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

ddekany

nagyúr

#11 S_x96x_S

#11 S_x96x_S
> Az APX-et viszont én is hiányolom a cikkbeli felsorolásból,
Majd bekerül a következő csomagba.
Az is lehet, hogy változtatnak rajta, vagy átnevezik mint az AMX-et ;

Az APX (aminek érkezését még nem ígéri a cikk) radikálisabban tűnik a x86 -> x86-64 átmenetnél is. Pl. 3 operandusos utasítások. Lényegében egy tök új ISA, erős ARM/RISC áthallásokkal. Csak úgy van tervezve, hogy lehessen egy szálon belül keverni x86-64 kóddal. Szóval akiket eddig esztétikailag zavart a legacy támogatás, ezzel szép nagy lapáttal rádobnának az ocsmányságra...
S_x96x_S veterán

#11
#10 hugo chávez
2025-10-15 09:42:24

Új Válasz
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

S_x96x_S

veterán

#10 hugo chávez

#10 hugo chávez
Az x86-S-t lelőtték, abból a belátható jövőben már nem lesz semmi (mondjuk én ezt nem is bánom, mert nem igazán láttam a jelentőségét).
Az APX-et viszont én is hiányolom a cikkbeli felsorolásból, mert az évtizedek óta az egyik legfontosabb újítása lesz az x86 ISA-nak, amivel végre "azonos szintre" kerül a modern RISC-ekkel (PowerPC, ARM64, RISC-V...).
Egy régebbi rövid cikk az APX-ről: [link]

> Az APX-et viszont én is hiányolom a cikkbeli felsorolásból,
Majd bekerül a következő csomagba.
Az is lehet, hogy változtatnak rajta, vagy átnevezik mint az AMX-et ;
hugo chávez aktív tag

#10
#3 Peter64
2025-10-15 07:30:55

Új Válasz
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

hugo chávez

aktív tag

#3 Peter64

#3 Peter64
Az OS majd 10 év múlva, mint a popcount most. De framework-ök, runtime-ok, compiler-ek és így az alkalmazások már sokkal hamarább. Ahol nincs egy adott új hw funkció ott vissza kell esni valami alap működésre.
Viszont az APX-et és az x86s-64-et nem látom felsorolásban vagy ez az egész lenne az? Talán az utóbbi nem tartozik ide, pedig nem ártana meglépni.

Az x86-S-t lelőtték, abból a belátható jövőben már nem lesz semmi (mondjuk én ezt nem is bánom, mert nem igazán láttam a jelentőségét).
Az APX-et viszont én is hiányolom a cikkbeli felsorolásból, mert az évtizedek óta az egyik legfontosabb újítása lesz az x86 ISA-nak, amivel végre "azonos szintre" kerül a modern RISC-ekkel (PowerPC, ARM64, RISC-V...).
Egy régebbi rövid cikk az APX-ről: [link]
Yutani nagyúr

#9
#8 Pikari
2025-10-15 00:47:46

Új Válasz
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

Yutani

nagyúr

#8 Pikari

#8 Pikari
Még legalább 20-30 évig biztosan elvegetál az x86-64 legalább irodai, gaming és ai célokra, utána remélhetőleg a risc-v, vagy valami hasonló arch elkezdi átvenni a helyét.

Addigra már meghalunk.
Pikari veterán

#8
#4 Cassi
2025-10-15 00:04:49

Új Válasz
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

Pikari

veterán

#4 Cassi

#4 Cassi
A tagfelvétellel nem kell foglalkozniuk, így könnyű haladni...

Még legalább 20-30 évig biztosan elvegetál az x86-64 legalább irodai, gaming és ai célokra, utána remélhetőleg a risc-v, vagy valami hasonló arch elkezdi átvenni a helyét.
Pikari veterán

#7
#1 laed
2025-10-15 00:01:10

Új Válasz
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

Pikari

veterán

#1 laed

#1 laed
Na jó, de mi fogja kihasználni? A Windows 12??

Amennyiben nem jár új regiszterek bevezetésével, akkor bármi használni tudja, nem igényeli a kernel módosítását.
Geri Bátyó addikt

#6 2025-10-14 22:08:00

Új Válasz
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

Geri Bátyó

addikt

LOGOUT blog

"Biztonsági szempontból messze a ChkTag a legfontosabb újítás"
Pontosan! Így nem kell azon vitázni, hogy melyik cég procijában van a több biztonsági rés, mert pont ugyan azok lesznek mindegyikben!
Nekem inkább az egységesített AVX tűnik lényegesnek, mert amit az Intel azzal művelt, az kabaré. Így majd rendesen lehet fejleszteni rá.
b. félisten

#5
#4 Cassi
2025-10-14 18:52:11

Új Válasz
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

b.

félisten

#4 Cassi

#4 Cassi
A tagfelvétellel nem kell foglalkozniuk, így könnyű haladni...

Nvidia beköszönhet talán .
Cassi őstag

#4 2025-10-14 18:02:53

Új Válasz
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

Cassi

őstag

A tagfelvétellel nem kell foglalkozniuk, így könnyű haladni...
Peter64 csendes tag

#3
#1 laed
2025-10-14 17:40:23

Új Válasz
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

Peter64

csendes tag

#1 laed

#1 laed
Na jó, de mi fogja kihasználni? A Windows 12??

Az OS majd 10 év múlva, mint a popcount most. De framework-ök, runtime-ok, compiler-ek és így az alkalmazások már sokkal hamarább. Ahol nincs egy adott új hw funkció ott vissza kell esni valami alap működésre.
Viszont az APX-et és az x86s-64-et nem látom felsorolásban vagy ez az egész lenne az? Talán az utóbbi nem tartozik ide, pedig nem ártana meglépni.
spect80 őstag

#2
#1 laed
2025-10-14 17:08:45

Új Válasz
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

spect80

őstag

#1 laed

#1 laed
Na jó, de mi fogja kihasználni? A Windows 12??

Vagy kitalálják hogy csak ezek meglétével fog futni.
laed senior tag

#1 2025-10-14 17:04:06

Új Válasz
Új hozzászólás
Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

laed

senior tag

Na jó, de mi fogja kihasználni? A Windows 12??