Hirdetés
- petipetya: Nagy chili topic. :)
- Luck Dragon: Asszociációs játék. :)
- Brogyi: CTEK akkumulátor töltő és másolatai
- eBay-es kütyük kis pénzért
- GoodSpeed: Nem vénnek való vidék - Berettyóújfalu
- Lenry: Windows 11 telepítése inkompatibilis gépre
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Sub-ZeRo: Euro Truck Simulator 2 & American Truck Simulator 1 (esetleg 2 majd, ha lesz) :)
- GoodSpeed: Ebes, a megtervezett falu!
- NASsoljunk: ZyXEL NSA-310 és az FFP
Új hozzászólás Aktív témák
-
Pikari
veterán
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
senior tag
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
senior tag
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
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
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
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
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
É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.
-
Pikari
veterán
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.
-
ddekany
nagyúr
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...
-
#11
S_x96x_S
addikt
hugo chávez
#10
S_x96x_S
addikt
válasz
hugo chávez
#10
üzenetére
> 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 ;
-
#10
hugo chávez
aktív tag
Peter64
#3
hugo chávez
aktív tag
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] -
#6
Geri Bátyó
addikt
"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á.
-
Peter64
csendes tag
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.
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. 
Új hozzászólás Aktív témák
- Bemutatkozott a Poco X7 és X7 Pro
- petipetya: Nagy chili topic. :)
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Milyen billentyűzetet vegyek?
- VR topik (Oculus Rift, stb.)
- Megérkezett a hardverszállítmány
- One otthoni szolgáltatások (TV, internet, telefon)
- Apple MacBook
- Gumi és felni topik
- Kuponkunyeráló
- További aktív témák...
- Intel Core i7-9700 Processor, 12M Cache, 4.70 GHz
- Intel Core i9-9900K 8-Core 3.6GHz (16M Cache, up to 5.00 GHz) Processzor!
- BESZÁMÍTÁS! Intel Core i9 9900K 8 mag 16 szál processzor garanciával hibátlan működéssel
- Intel Core Ultra 5 235 14-Core (24M Cache, up to 5.00 GHz) LGA1851 OEM PROCESSZOR!
- Eladó i7 7700
- BESZÁMÍTÁS! ASUS ROG STRIX RTX 3070Ti 8GB videokártya garanciával hibátlan működéssel
- MikroTik CCR1009-7G-1C-1S+ Cloud Router
- Apple iPhone 13 /128GB /Kártyafüggetlen / 12 Hó Garancia / akku: 85%
- Bomba ár! Dell Latitude 5491 - i7-8850H I 16GB I 512GB SSD I 14" FHD I HDMI I Cam I W10 I Gari!
- Lian Li LCD-s 360mm-es vízhűtés akciós áron eladó!
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest
Cég: NetGo.hu Kft.
Város: Gödöllő