- Karácsonyfaként világíthat a Thermaltake új CPU-hűtője
- Az USA vizsgálja a RISC-V kínai terjedésének kockázatát
- Kicsit extrémre sikerült a Hyte belépője a készre szerelt vízhűtések világába
- Egészen nagy teljesítményspektrumon fedné le a mobil piacot az AMD
- Kihívás a középkategóriában: teszten a Radeon RX 7600 XT
- Vezetékes FEJhallgatók
- Sony MILC fényképezőgépcsalád
- VR topik (Oculus Rift, stb.)
- Modern monitorokra köthető 3dfx Voodoo kártya a fészerből
- AMD Ryzen 9 / 7 / 5 7***(X) "Zen 4" (AM5)
- Milyen cserélhető objektíves gépet?
- ZIDOO médialejátszók
- Azonnali informatikai kérdések órája
- Egészen nagy teljesítményspektrumon fedné le a mobil piacot az AMD
- Milyen asztali (teljes vagy fél-) gépet vegyek?
Hirdetés
-
Spyra: akkus, nagynyomású, automata vízipuska
lo Type-C port, egy töltéssel 2200 lövés, több, mint 2 kg-os súly, automata víz felszívás... Start the epic! :)
-
Kicsit extrémre sikerült a Hyte belépője a készre szerelt vízhűtések világába
ph A cég megoldása centralizált vezérelhetőséggel, masszív radiátorral és robusztus ventilátorokkal igyekszik vásárlásra csábítani.
-
Agyi chipes gyártóba fektetett a kriptocég
it A Tether 200 millió dollárt fektet a Blackrock Neurotech agyi chipes vállalatba.
Új hozzászólás Aktív témák
-
#95904256
törölt tag
Ha visszafelé nem kompatibilis, akkor talán nem is muszáj hogy x86-os utasításokat fogadjon. Ezt csak azért mondom, mert így még egyszerűbb utasításdekóderre lenne szükség, ami jól jön ha alacsonyan akarják tartani a fogyasztást. Sok magnál kifejezetten jól jöhet... de ez csak egy gondolatmenet.
-
Rive
veterán
Ami kimarad, azt meg - nagy szükség esetén - akár elrendezheti az OS egy megfelelő kivétellel
Azzal együtt, amit még előkerestél, elég durva lehetőségek vannak benne. EZ már nem csak az a mostani GPU-bebirizgálás általános számításokra, hanem valami jóval keményebb.
/// Nekünk nem Mohács, de Hofi kell! /// Szíriusziak menjetek haza!!!
-
fLeSs
nagyúr
Azért nincs más ISA-hoz assembly topik, mert az asztali rendszerekben az x86 terjedt el. És az ilyen topikokat egyébként sem a PH-n kell keresgélni.
"miért ne lenne 'beszélő viszonyban' egymással a két cég?"
Az Intelnek szent meggyőződése, hogy az AMD-től nem vesz át semmit, mert ő uralja a piacot, szóval ha ő megvalósít vmit, akkor úgyis az fog elterjedni. És végülis eddig igazuk is volt, egyedül az x86-64-nél kényszerültek rá a másolásra, de az EM64T-t is saját fejlesztésként tüntetik fel (másképpen sérülne a büszkeségük).
Az AMD ilyen helyzetben (mint a SIMD utasításkészletek esetében) szarban van, mert ha külön utat jár, és saját fejlesztését propagálja, akkor fennáll a veszélye, hogy azt nem fogják támogatni, mert az AMD-nek jóval kisebb a piaci részesedése (3DNow!). Külön erőforrásokat kell mozgósítani annak érdekében, hogy rávegye a fejlesztőket a használatára. Az AMD-nel erre nincs pénze, elég megnézni a VGA-frontot, szinte az összes idei játékot NV-re optimalizálták.
Ha viszont beáll az Intel mögé, akkor x-edik alkalommal is elkönyvelik, mint második gyártót. Viszont így biztos lehet a termék profitábilis mivoltában (vagy legalábbis széleskörű elterjedésében).[ Szerkesztve ]
"I press keys on a keyboard all day and click a mouse in front of a glowing rectangle. Somehow that turns into food and shelter."
-
kisfurko
senior tag
Az Itaniummal azért más a helyzet, mert az nem a fő mag(ok) kiegészítéseként készült, mint ezek az inorder kis x86 magok. Továbbá ilyen egyszerű magokra nem olyan bonyolult fordítót csinálni, mint egy Itaniumra.
A probléma az x86-tal ott van, hogy egy bonyolult dekóderre van szükség, mert mindig csak hozzátákoltak valamit. Érdemes az SSE utasítások kódolását megnézni. De ez még hagyján, de a korlátozott regiszterkészlet, idióta operandusok miatt egy fordítót sokkal nehezebb hozzá csinálni. Tudom, hogy van már fordító, de azt úgyis folyton át kell írni, mert hiába ugyanazt futtatja egy P4, mint egy Pentium, tök máshogy kell kódot generálni hozzá, mert ügyesen be kell tolni a megfelelő x86 utasításokat, hogy a micro-opok optimálisan kihasználják az erőforrásokat.
Egyébként nem tudom, mennyire működőképes a PowerPC kódfuttatás x86-on, gondolok itt a Maces átfordítóra, de ha azt meg tudták csinálni egész hatékonyra, akkor nem tudom, mi lenne az akadálya egy sima RISC-es magnak. OK, nagyobb utasítás cachere lenne szükség, de talán egy kisebb utasításkészlet mellett még ez sem biztos.
Más architektúrák meg azért nem közismertek, mert nem hozzáférhetőek az átlagember számára (futtatás). Én nagyon sajnálok mindenkit, aki 8086-ossal kezdi az assembly tanulást, egy életre elveszi az ember kedvét (sajnos az iskolákban ilyen idiótaságot tanítanak). De még ha védett módban, legfrissebb utasításkészletet is tanul, akkor is rémálom. A Motorola 68k, vagy hogy ma még létező dolgot is említsek, az ARM fényévekkel kultúráltabb. Azt simán lehet assemblyben tolni, mert nem dől össze a világ, ha mégis szükség van egy másik regiszterre pl. A paraméterátadás is regiszterekben megy, amíg értelmes számú paraméter van. Tehát elég egyszerű assembly kódot illeszteni C-hez. x86-on meg gusztustalan.
-
dezz
nagyúr
Hááát... Ha szerinted jobb a pár regiszter (mondjuk SSE-sből már van jópár, főleg x64-en), amit össze-vissza cserélgethetsz, mint a sok, aminél könnyebben fejben tarthatod, miben mi van, és cserélgetés sem viszi el az időt, meg tömíti a kódot... Aztán, az utasításkészlet és a szintaxis áttekinthetősége, a sokféle címzésmód (source és destination esetén is többnyire szabadon -- köztük a PC-relatívok, amik által módosítás nélkül is relokálható a kód), a 8/16/32/64 bit ügyes kezelése (ugye az x86-ra szokták mondani, hogy egy 8 bites proci 16 bites kiterjesztésének 32 bites kiterjesztésének 64 bites kiterjesztése...
-- miközben a 68k és a PPC eleve 32 bitesek voltak, és utóbbinál a 64 bites operandusok kezelése sem hoz különösebb változásokat), stb.Lényegében az x64-gyel pár lépéssel közelebb került az x86 család a fent említettekhez. (68k esetén persze leszámítva a 64 bitet és a SIMD-et.)
Hogy azért egy furcsaságot is mondjak PPC-nél, ami előtt én is vakargatom a fejem, hogy ezt miért kellett: 68k-val is ellentétben fordított bitszámozás.
De persze tudom, a különféle platformok mívelői általában úgysem igazán tudják meggyőzni egymást...
Nem is tudom, hány évtizedes már ez a vita. [ Szerkesztve ]
-
kisfurko
senior tag
Egyébként ez a regiszterekben való elveszés is csak azért van, mert az x86-os assemblerek bénák (voltak?). Simán aliast adsz egy regiszternek. Vagy ha C-be ágyazott assembly, akkor lokális változók, s a fordító lefoglalja neked a regisztereket. Ugye x86-nál ezek a megoldások szóba se jöhetnek, mert nem egyenrangúak a regiszterek.
De még az SSE se megváltás, mert nincs annyi regisztered, hogy egy nyamvadt 4*4-es mátrix beférjen, ergó nincs gyors transzponálás. Nincs beépített shuffle, meg maszkolás stb. Megnézhetné mondjuk intel a PSP vektoregységét, hogyan kéne minimum kinéznie egy vektoregységnek. De az AltiVecről is vehetett volna példát. És ugyanez igaz volt az MMX-nél, de még a 8087-es koprocesszornál is.
No, egész cikket lehetne írni, hogy miért nem jó az x86, de már belefáradtam. Nekem meggyőződésem, hogy inteléknél architektúrát nem tudnak tervezni, viszont elektronikai megvalósításban verhetetlenek. -
#95904256
törölt tag
Nem nagy belelátással, de azért ismerem a kezdő x86 assembly-programozók hozzáállását. Azt a hét regisztert sem merik kihasználni, ami rendelkezésre áll, EAX-EDX az isten, a többi mintha tabu lenne, nagyobb lehetőségek között elvesznének (nem sokban különböznek az x86 compiler-ektől ).
Egy compiler sem lesz sosem többre képes mint az a programozó aki azt írja, pláne ha igyekszik mindenféle előírásokat betartani. A jelenlegi processzorokban a register renaming rendkívül hatékony, így a programozói regiszterekben való tobzódás tényleg csak hab a tortán... Mondjuk, én kifejezetten ínyenc és édesszájú vagyok.
-
kisfurko
senior tag
Hát pl. vannak okos assemblerek, amik átrendezik az utasításaidat, hogy ha ez kivitelezhető, és szerintük ezzel lehet jó átlapolódást csinálni két utasítás között. Az általam ismert assemblerek közül az x86-osok voltak a legrosszabbak. Talán a NASM az, ami a jó irányt mutatja. De annak ellenére, hogy megszállott assemblyző vagyok, már nem látom értelmét a nem C(++)-be ágyazott assemblynek.
Az alias nem kivitelezhető x86-on értelmesen, pont ezt írtam, mert nem RISC-es utasítások vannak, tehát egy változó lehet memória és regiszter is, tehát behelyettesítéskor baj lehet.
A C-be ágyazott assembly ilyen:
inline int distsqr(int x1, int y1, int x2, int y2)
{
int temp1, temp2, temp3;
asm
{
sub temp1, x2, x1
mul temp2, temp1, temp1
sub temp1, y2, y1
mul temp3, temp1, temp1
add temp1, temp2, temp3
}
return temp1;
}Ez nem tartalmaz egy regiszterre való utalást sem, és éppen ahova befordítod, úgy fognak változni a felhasznált regiszterek. Persze ehhez az kell, hogy regiszterekben adódjanak át a paraméterek. Már nem vagyok képben, hogy x86-on van-e már ilyen paraméterátadás.
Jajj, hülyeséget írtam, bocs, két 4*4-es mátrix nem fér el úgy, hogy össze is tudjad szorozni őket.
A transzponálásra pl. nincs is szükség jó vektoros egységeknél, mert tudsz transzponálva olvasni (natívan, vagy maszkok és shuffle). A beépített itt most nálam azt jelenti, hogy minden operandushoz lehet rendelni tetszőleges shuffle-t, maszkot, lásd pl. vertex shaderek.Hajjaj...
A PSP-ben egy nagy regisztertömb van, és minden utasítás tetszőlegesen címzi azt meg (sor-, oszlopvektor, mátrix, transzponált mátrix). Mindezt 1, 2, 3, vagy 4 dimenziósan. Tud szögfüggvényeket, pillangó transzformációt, keresztszorzatot, skalár szorzatot, 3D-hez szükséges konstansok vannak, 2*2-es determinánst, mátrix-vektor szorzást, kvaternió szorzást, random számot, forgatási mátrixhoz együtthatót számol. Jó, ezeket nem egy órajel alatt végzi el, de ez egy hordozható eszközben van. De akár a vertex shader assemblyt is össze lehet hasonlítani az SSE-vel.
Az x87-es FPU meg a stack szervezésével egy másik óriási rémálom. Mindezt szintén a rengeteg 8db regiszterrel. Vö. Motorola 68881 és intel 8087.Egyébként sok-sok évet programoztam x86-ot, de szerencsére megismertem más architektúrákat is, így ha választhatok, akkor nem x86. Az ARM-ot jobban élvezem, annak ellenére, hogy csak pár száz MHz-es. De ha lenne x86 assembly munka jó fizetésért, akkor nem utasítanám vissza, mert mégis csak assembly
-
ddekany
veterán
Na nehogy már vitás legyen, hogy milyen is az x86 ISA. Egy ritka ocsmány, toldozott-foldozott... fúj és kész, már csak esztétikailag is rémálom egy vérbeli kocka számára. (Ezért is nyert a piacon... legalábbis az élmezőnyböl általában a technikailag rondább megoldás győz, követve "a mindent el kell b*szni, hogy ne legyen jó" filozófiát.
)Ami az assembly nyelven való programozás könnyebbségét illeti, én ott is erősen kétlem, hogy az x86 a jobbak közt lenne. De mindegy is, mert már jó ideje ezredrangú kérdés ez, mivel nagyon kevés kódot írnak assembly-ben PC-re. Sokkal fontosabb lenne, hogy a CPU-nak mennyire fekszik az ISA, meg esetleg a compiler-ekenek. És bár a mai CPU-k már nagyon ügyesen kerülgetik ennek az ISA-nak a problémáit (kevés regiszter, stb), talán még mindíg gyorsabb lenne egy normális ISA-val... de minden esetre biztos kevesebb hő és tranzisztor.
[ Szerkesztve ]
-- miközben a 68k és a PPC eleve 32 bitesek voltak, és utóbbinál a 64 bites operandusok kezelése sem hoz különösebb változásokat), stb.
A transzponálásra pl. nincs is szükség jó vektoros egységeknél, mert tudsz transzponálva olvasni (natívan, vagy maszkok és shuffle). A beépített itt most nálam azt jelenti, hogy minden operandushoz lehet rendelni tetszőleges shuffle-t, maszkot, lásd pl. vertex shaderek.
Új hozzászólás Aktív témák
ph Az általános célú és grafikus gyorsítók alapját képező chipekből ez év végére még csak a minták várhatók.
