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

• #23 kisfurko senior tag

  Új Válasz 2008-01-17 23:51:52 #23

  Ú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

  Privát üzenet küldése

  

  kisfurko

  senior tag

  Ezt az elképzelést az IBM már implementálta Cell néven. Ugyanazok a problémák fognak felmerülni itt is, mint ott, hiába az x86-os kód (ami inkább teher), meg meglévő fordító, a rendelkezésre álló szűkös sávszélességgel/erőforrásokkal okosan kell bánni.
  Mindenesetre kíváncsian várom.
  Vajon azokat az 512 bit széles SIMD-eket hogyan fogják etetni?

• #29 kisfurko senior tag dezz #27

  Új Válasz 2008-01-18 12:06:48 #29

  Ú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

  Privát üzenet küldése

  

  kisfurko

  senior tag

  válasz dezz #27 üzenetére

  Ez mind igaz, de az intel mindig beveti, hogy a nép felől közelít. Senki nem gondolta volna, hogy a 8086 valaha is sikeres lesz, sőt az egész x86 vonal, és lám, mi van. Ezeket a kérdéseket nem szakemberek döntik el, hanem idióta üzletemberek. Azok pedig ha rövid távon tudnak spórolni, az már elég nekik. Biztos, hogy olcsóbb lesz, mint egy Celles rendszer. Meg futtassa a régi kódot. Ennyi elég a világnak. Majd mi dörmöghetünk legfeljebb

• #36 kisfurko senior tag P.H. #33

  Új Válasz 2008-01-19 12:35:02 #36

  Ú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

  Privát üzenet küldése

  

  kisfurko

  senior tag

  válasz P.H. #33 üzenetére

  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.

• #39 kisfurko senior tag P.H. #37

  Új Válasz 2008-01-19 18:42:41 #39

  Ú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

  Privát üzenet küldése

  

  kisfurko

  senior tag

  válasz P.H. #37 üzenetére

  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.

• #40 kisfurko senior tag dezz #38

  Új Válasz 2008-01-19 18:46:59 #40

  Ú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

  Privát üzenet küldése

  

  kisfurko

  senior tag

  válasz dezz #38 üzenetére

  Fordított bitszámozás? Itt little-endianra gondolsz?
  Egyébként én big-endian hívő vagyok.

• #46 kisfurko senior tag P.H. #42

  Új Válasz 2008-01-20 12:50:22 #46

  Ú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

  Privát üzenet küldése

  

  kisfurko

  senior tag

  válasz P.H. #42 üzenetére

  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

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