szép-szép.
"x86 utasításkészlet egy változatára alapoznak"
Az x86-nak több változata is van? 
Amúgy ray-tracinges Quake 4-gyel demózták ezt a larrabeet, szal valszeg nem directx-hez készül.
Sztem eleinte csak sima számolóként fogják alkalmazni, aztán amikor már elég alacsony lesz a csíkszélesség, akkor beraknak egymás mellé 32 magot 5 ghz-en, oszt jó lesz VGA-nak is 500 wattos fogyasztás mellett. 
[ Szerkesztve ]
2009 kicsit még odébb van, de ez már most jónak tünik 
Amugy nem egy ehez hasonló grafikus magot akarnak majd a 32nm-es Nehalemekbe?
"Ha a premier után kiderül, hogy DirectX alatt az Intel mégsem olyan jó, a Havokra támaszkodva esetleg a játékfejlesztők és a játékosok figyelmét is elterelheti a látvány felől más jellemzők, így a fizika és az AI irányába."
Rendkívül intelligens és reálisan mozgó pixelek terelik majd el a figyelmünket a 320x240-es felbontásról. 
"Only two things are infinite, the universe and human stupidity, and I'm not sure about the former." (Albert Einstein)
Az x86-nak több változata is van?
Elsőre az ugrott be, hogy lehet, nem lesz bennük Microcode ROM, esetleg még read-modify-write utasítások sem, és csak a közvetlenül 1 (fused) micro-opra fordítható utasítások maradnak. Nem lenne nagy érvágás.
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies
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. 
Csakhogy akkor kezdhetik nulláról az egészet, az eredmény pedig egy teljesen új rendszer lenne, nem hiszem hogy tapsolnának örömükben a programozók...
"Only two things are infinite, the universe and human stupidity, and I'm not sure about the former." (Albert Einstein)
Ezt hogy érted?
Mit kellene nulláról kezdeni?
És miért szomorkodnának a programozók?
Megjegyzem hogy az AMD és nVidia GPU-k sem x86 kompatibilisek, mégis ott lapulnak egy halom PC-ben...
x86-hoz van egy rakat fejlesztésük, nagyrésze mehetne a levesbe és fejleszteni kéne mást.
Persze, ott lapulnak 3D célhardware-nek, de ezt nem 3D gyorsítónak szánják, más célokra meg az AMD/nVidia megoldásait se nagyon akarják használni.
"Only two things are infinite, the universe and human stupidity, and I'm not sure about the former." (Albert Einstein)
Azt lehet tudni hogy az Intel mennyire jelentős fejlesztői kapacitást szánt erre a vga-s projectre? Csakmert ha pl nagyobbat mint ami az nV-nek van akkor szép dolgok várhatóak sztem...
részhalmaz, az más.
egyébkétn egy RISC felépítéssel jobban járnának, amihez nem kell dekódoló, márha a tranzisztorszámot->melegedést és fogyasztást nézem.
de ez eleve halott ötlet, mert ha az a cél, hogy minél nagyobb piacot hódítsanak meg vele (nem csak VGA-ba lesz larrabee), akkor kell az x86, mert az a legelterjedtebb, és ezzel egy tökéletesen tökéletlen ISA menetelésének adnak további lendületet.
[ Szerkesztve ]
(#12) janpotocki válasza VaniliásRönk (#9) üzenetére
a larrabee-t grafikus gyorsítónak is szánják. az amd/nv grafikus processzorainak pedig hasonlóképpen igyekeznek helyet találni az általános célú gyorsítók világában. egyelőre persze nem veszik tömegével őket, a szoftveres hátterük is kialakulófélben van még csak, de akik megveszik, komoly summákat fizetnek érte
biznisz iz biznisz
Lényegtelen lenne mekkora a kapacítása az Intel-nek, a raszterizálásban képtelen lenne beérni az AMD-t és az nVidiát. Ekkora tapasztalathiányt nehéz lenne pótolni pusztán "erőből". Nem véletlen, hogy a Ray-Tracing-et reklámozzák inkább.
A semmi az nem nincs, hanem van. Ha a semmi van, akkor nincs semmi, de ha nincs semmi, akkor valami van, de az nem semmi.
Szerintem is általános célra kívánják használni, nem pedig CPU-ként. Annak nem is használhatnák ha csak részben kompatiblis a jelenlegi operációs rendszerekkel.
Ebből következik hogy ígyis-úgyis új fordítóprogramra lesz szükség, akkor meg miért ne lehetne egy hatékonyabb arhitektúra mögötte? Valamint az Intel-nek nem csak x86-os fejlesztései vannak.
A nem x86-os fejlesztéseit eléggé elhanyagolta, ha jól tudom. (szerk.: gondolok itt az Itaniumra, mást nem hiszem hogy fel lehetne használni ilyen célra)
Szerintem a Fusion miatt próbálják az x86-hoz kapcsolni, az teljesen x86 és DX kompatibilis lesz.
[ Szerkesztve ]
"Only two things are infinite, the universe and human stupidity, and I'm not sure about the former." (Albert Einstein)
Kifejezetten általános célokra szánják, kifejezetten x86 utasításkészletre alapozva. ("It will be easily programmable using many existing software tools, and designed to scale to trillions of floating point operations per second (Teraflops) of performance. The Larrabee architecture will include enhancements to accelerate applications such as scientific computing, recognition, mining, synthesis, visualization, financial analytics and health applications." [link], bár elég régi, ez újabb.) A jelenlegi x86-fordítókat minimális módosítással kompatibilissé lehet tenni; lehet, hogy 2009-ben pl. olyan Visual C fordítót kaphatsz, ami tud erre is fordítani.
Ez a gondolatmenet így, tömören leírva kifejezetten szimpatikus:
The Larrabee architecture could be characterized as the anti-GPU entry. The overall approach is an attempt to evolve the CPU into a terascale data parallel engine. According to Intel, Larrabee will be a manycore (i.e., more than 8 cores) device and will be based on a subset of the IA instruction set with some extra GPU-like instructions thrown in. Intel has not elaborated on how it intends to do this, but one could imagine super-sized SSE units with just enough x86 CPU silicon to enable general-purpose flow control and data access. The first product release will probably come in 2009, but Intel says it may have something to demo as early as next year.
The idea behind Larrabee is to bring both traditional graphics processing and data parallel computing under the IA umbrella. I'm not going to talk about the traditional graphics side of the story here (I'll let the game weenies argue about the advantages of ray-tracing over rasterization.) What's interesting about Larrabee and its GPU brethren is the extent to which a graphics engine can become a general-purpose computing engine without compromising its performance.
The combination of a data parallel engine with more of the general-purpose flexibility of a traditional CPU could offer a powerful model for scientific computing applications, which usually consist of an irregular mix of matrix math and other logic. One of the drawbacks of traditional GPUs is that they depend upon an accompanying CPU for virtually all of the non-vector logic. That's fine if the application divides neatly between a vector computing kernel and the rest of the application logic in such a way as to keep both types of processing engines busy. But if it doesn't, the software developer has to find a way to tease out enough parallelism for the GPU to make sending the vector data on a round trip from the CPU worthwhile. This will only get worse in the future, since chip-to-chip bus performance is not expected to keep pace with either CPU or GPU performance.
[ Szerkesztve ]
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies
Úgy tudom az XScale is az Intel a kezében van. Illetve jó pár mobiltelefonban, PDA-ban, GPS készülékben...
Gondolod az jó alap lenne? Nem értek hozzá csak kérdem. 
"Only two things are infinite, the universe and human stupidity, and I'm not sure about the former." (Albert Einstein)
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.
Szerviz és javítgatás nálam, mert válság van /// Nekünk nem Mohács, de Hofi kell! /// Szíriusziak menjetek haza!!!
Tetszőlegesen allokálható általános kraft
Resistance Is Futile. You will be assimilated!
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?
Gondolom (most már látom is), többeknek feltűnt a Cell procival, pontosabban annak SPE-blokkjával való hasonlóság. Persze vannak különbségek is. Röviden leírnám ezeket.
Főbb hasonlóságok:
- Egyszerűsített, de SIMD-feldolgozásra rá gyúrt, in-order magok.
- A GPU-k önmagukban "butácska" shader procijaihoz képest viszont közelebb állnak a szokásos CPU magokhoz.
- Magonként 256 KB belső memória (direkt fogalmaztam így).
- Ring-busz a magok és a memóriavezérlő között.
Főbb különbségek:
Cell SPE-blokk: -- Larrabee:
- 1 thread (dual-issue) -- 4 thread
- full RISC -- vélhetően (manapság) szokásos x86 felépítés
- relatíve kicsi magok (több fér el) -- vélhetően nem olyan kicsi magok
- 256 KB (~ L1 sebességű) dedikált belső ram/SPE (gyors adatcserével az SPE-k között) -- 256 KB shared L2 cache
- a belső ram 1 byte-ja effektív 1 byte -- cache esetén cache-line-okról beszélhetőnk, ami többszörös méretet jelent -> megint csak több fér el az elsőből
- külső-ram elérése DMA-val [*] (MMU is van) -- vélhetően a szokásos memória-hozzáférés
A Cell esetén gyakorlatias szempontból hátrány a main ram közvetlen el nem érése (csak DMA-val[*]). Így mintegy rá vannak kényszerítve a programozók a belső ram optimális használatára. Ez viszont találkozik azzal, hogy jóval könnyebb ram-használatra optimalizálni, mint cache. És ha már "itt tartanak", a külső-ram eléréseket is optimálisan oldják meg. Maga a feladat, legalábbis a "Cellre alkalmazás" az architektúra figyelembevételével törénik meg, így többnyire elég optimális lesz az eredmény.
A Larrabee-nél nincsenek erre ennyire rákényszerítve, mert ugye kis túlzással egy sima recompile után (persze valami eleve párhuzamosított kódra gondolok) futhat a kód, mivel közvetlen külső-ram elérés van. Azon még kicsit csiszolnak, és úgymond kész is. Így aztán nem igazán használja ki olyan mértékben az elméletileg rendelkezésre álló teljesítményt. (Bizonyos feladatokban pl. könnyebben összeveszhetnek a külső-ram sávszélen.)
([*] Azért - mint ahogy nemrég a Cell főtervezője elmondta - itt nem valami nehézkes, lassan beindítható DMA-zásról van szó. A memóriavezérlő is jópár kérést pufferel, stb. stb. - gondolkodtak is, hogy valami új nevet adnak a dolognak, hogy ne legyen annyira riasztó.)
Nos ezek után érdekes lesz szemlélni a két architektúra versenyét... (Persze vannak olyan alkalmazások is, amikben vagy eleve az egyik, vagy eleve a másik fog jobban szerepelni.)
Van egyébként Cell alapú, komolyabb ray-tracing alkalmazás is. Elég jól skálázódik a felhasznált SPE-k számával:
Cell (vs. G80) @Ray-tracing
"Off to Siggraph"
Interactive Ray Tracer for Cell Broadband Engine (IBM)
[ Szerkesztve ]
"256 KB shared L2 cache" -> akartam mondani: (256*mag) KB shared L2 cache
És még egy link: Cell and the Boeing 777 at SC07
[ Szerkesztve ]
Nos ezek után érdekes lesz szemlélni a két architektúra versenyét...
Nem lesz verseny. Az X86-kompatibilitás - még ha nem is teljes - szokás szerint mindent eldönt majd, nagyon rövid idő alatt.
Szerviz és javítgatás nálam, mert válság van /// Nekünk nem Mohács, de Hofi kell! /// Szíriusziak menjetek haza!!!
Azért számoljuk hozzá a következőket:
- Az IBM-ről van ugye szó, ami ma is sok területen versenyez az Intellel. Desktopot az Apple átállásával mondjuk bukták, de ott vannak a szerverek, munkaállomások, embedded rendszerek, szuperszámítógépek.
- Ugyanez uarch. szinten: a Power mikroarchitektúráról beszélünk (bár az SPE-k kódja csak távolról hasonlít rá, ott van a Poertes főmag, ugyanazokon a fordítókon, ugyanazokban a fejlesztési környezetekben fordítható kód mindkettőre), ami a fent említett területeken versenyben van az x86-tal.
- A Cell már évek óta a piacon van, és több területen el is kezdődött a használata.
- Ugyanez elmondható a fejlesztési környezetekről is. C++ fordítók, IBM Octopiler (automatikus párhuzamosító+SIMD-esítő fordító), kimondottan tudományos célra készült HPC/szuperszámítógépes fejlesztési környezetek, szoftverkönyvtárak, egyéb fejlesztői háttéranyagok, stb.
Szóval van/lenne mit behoznia az Intelnek.
[ Szerkesztve ]
- hiba -
[ Szerkesztve ]
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
Szinte 100% hogy a Larrabbe-nak a ray-tracing lesz az egyik fő feladata.
Szépen beleteszi a cpu mellé, egybe integrálva és már nyert is.
Amilyen előnnyel rendelkezik jelenleg cpu szinten az amd-vel szemben és a kilátások szerint ez nem csökken, hogy képes fájdalom mentesen betenni.
Annó amíg az x87-es külön lapkák voltak addig volt más cégnek is esélye, de amint az intel meglépte az integrációt, már esélye sem volt másnak.
Ehhez még az sem kell, hogy jobb legyen, mint a cell.
Power
Nem egészen értem, hogy jön ide (illetve oda) az AMD. De ha már szóba hoztad: nagyjából egy időben hozza ki az Intel és az AMD a CPU mellé pakolt GPU-t (először mindkettő MCP-s [Multi-Chip Package] lesz, azaz két külön lapka lesz), mégpedig egyelőre a belépő szintre, illetve laptopokba, ennek megfelelő teljesítménnyel, lényegében a chipsetbe integrált grafika kiváltására. Később az AMD tervezi (legalábbis tervezte, egyelőre úgy tűnik, félre lett téve [vagy külön tokban oldják meg, egy Opteron helyén többutas rendszerben] - persze így desktopon nem sok keresnivalója lesz, de a GPGPU nem is desktop vonalon a legaktívabb) nagyobb teljesítményű GPU-féleség beiktatását, GPGPU célokra. Utána(?) meg jön náluk az SSE5.
A cikkben látható slide-okon nem szerepel normál CPU mag a Larrabee-ben, sőt a többutas rendszerben is csak ők láthatók. Valószínű tud annyit önmagában is, hogy a kisebb teljesítményigényű hagyományos programok is elfutnak rajta, a teljesítményigényesebbek meg eleve rá vannak fordítva, optimalizálva.
Még1x leírnám, hogy az IBM Power vonala (ha már ezt a nevet választottad, illő lenne tudnod, mit jelent ez a számtechben ) jelenleg is sikeresen versenyez az Intel megoldásaival több jelentős területen.
[ Szerkesztve ]
Az Intel megint a 'végletekből végletekbe' játékrendet mutatja be, mint pl. az órajel utáni IPC-növelés (ami manapság megint átcsapott órajel-versenybe - tick-tack? -; de ugyanez volt kicsiben a 486-Pentium-PPro idején is). SZVSZ most nem akarja azt, ami az Itaniummal történt, hogy megfelelő fordító (vagy API, amibe a programozók nagyrészt nem látnak - közvetlenül - bele) meglétén múljon egy nagy számítási kapacitású termékének általános sikere.
"hiába az x86-os kód (ami inkább teher)"
"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."
Miért van ekkora ellenérzésed az x86-felépítések iránt? Azt hiszem, mindketten ismerjük a korlátait, de még sincs általánosan más architektúrákra assembly topik a fórumokon. És ha lenne is, melyeket lehetne kézzel annyira idő-/költség-/erőforrás-hatékonyan programozni, mint egy x86-ot (~ library-k)? SZVSZ az Intel most erre alapoz.
Általánosan:
Itt az eredeti cikk, aminek egy részét idéztem #17-ben.
"Like Intel, AMD has hinted at adding GPU-type instructions to the x86 ISA to allow software to work seamlessly with the graphics engines via a standard compiler/runtime. If AMD and Intel were on speaking terms, they could forge a common GPU ISA, which would be much appreciated by the GPGPU ecosystem. It could also serve to blunt NVIDIA's lead, and probably force the company to adopt what would be an industry-standard GPU interface. In the short term, standards are unlikely. Everyone involved has their own vision of how the GPU should evolve into its new role."
Rövid távon tényleg nem látszik hasonlatosnak az Intel és az AMD megoldása, de miért ne lenne 'beszélő viszonyban' egymással a két cég?
[ Szerkesztve ]
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies
A PowerPC-t, vagy (annak idején) a 68k-t sokkal jobb (volt) asm-ben programozni, mint az x86-ot. Ezek mellett (főleg a 68k) az x86 elbújhat...
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 ]
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.
Az érdekes lesz, hogy az Intel hogy fog hozzáállni az SSE5-höz. Talán ez lehet még olyan ütőkártya az AMD kezében, mint az x64 volt, és ez már teljesen készen áll. ("These instructions use opcodes 0F 24 00–FFh and 0F 25 00–FFh.")
Vagy átveszi, vagy teljesen új, önálló útra vezeti az x86-vonalat: a Larrabee és utódai elég erős indokok lehet ahhoz, hogy valamikor a jövőben végleg lekoptassák az x86 ISA feleslegesen magával cipelt részeit, CPU szinten is, (pl. a rep movs típusú utasításoknál megjelenése óta sokkal gyorsabb az SSE-k non-temporal megközelítése, csak ugye a megszokás...) és értelmesen egészítsék ki.
Még mindig: ""Processor" shall mean any Integrated Circuit or combination of Integrated Circuits capable of processing digital data, such as a microprocessor or coprocessor (including, without limitation, a math coprocessor, graphics coprocessor, or digital signal processor) that is capable of executing a substantial portion of the instruction set of an AMD Processor or an Intel Processor."
Az Intel vagy marad a kétoperandusú műveleteknél és csak a futtatási SIMD-egységeket szélesíti ki, vagy átveszi az SSE5-öt (egy részét), vagy ugyan alkalmazni fog többparaméteres utasításokat, csak teljesen más gépi kódokkal (na ez szép lesz).
"És az ilyen topikokat egyébként sem a PH-n kell keresgélni."
Nem is itt hiányoltam, úgy általában. Azt gondolom, az x86 assembly valahol az 'általános műveltség' része. De az is jó (de flame-keltő) kérdés lenne, hogy miért pont ez terjedt el.
dezz: ez szerintem csak szimpátia (részlet)kérdése, vagy azé, hogy ki min kezdett, mióta a hardware tényleg tudja tartani a lépést a kódja komplexitásának növekedésével. Nekem x86-on könnyebb programozni, kicsi registerkészlettel, viszont jó adag utasításonkénti sideeffect-tel. (Amúgy szerintem egy 'teljesen igazságos világ' az IA64-féle megközelítést használná már - a programozó programíráskori 'miért'-jei is kerüljenek bele közvetlenül a gépi kódba, ne csak a 'hogyan'-jai, mindez terjengős végeredmény nélkül.)
kisfurko #36: ősszel szabadidőmben elkezdtem átolvasni az összes eddig PH!-n megjelent processzor-hírt és a topikjaikat, ismerem ezt is, ezért kérdeztem. A 8086 oktatására vonatkozó résszel egyetértek, én 32 bites valós móddal kezdtem, aztán gyorsan vissza kellett térnem egy időre 16 bitre - rémálom -, ezt azt hiszem, írtam is egyszer az assembly-topikban.
Lehet, hogy kicsavart a gondolkodásom, de úgy érdemes elkezdeni egyre közelebb kerülni egy hardware-hez, ha tudod, mire képes, és egy idő után ki tudod jelenteni, mire lenne szükség a nagyobb hatékonysághoz (ne akarj profi felhasználó maradni, légy kezdő alkotó, egy szinttel feljebb, mindíg). Ekkor látszik, hogy felfogtad a lényegét - ha mégsem, profi felhasználónak is jó lenni.
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 ). Őszintén szólva én is elvesznék, ha egy regisztert a kódban képernyőnként egyszer látnék, az esetek többségében maradnék csak néhány használatánál. De ezzel meg megint visszakerülünk oda, hogy ez szimpátia/előélet kérdése.
[ Szerkesztve ]
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies
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 ]
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.
Fordított bitszámozás? Itt little-endianra gondolsz?
Egyébként én big-endian hívő vagyok.
ezek után nem csodálkozom...
Miről beszélsz? A szavakat nagyjából értem, de a mondandót nem.
Csak hogy ne az legyen a válasz, hogy olvassak utána, lámaként, lépésenként kérdezek:
- Egyébként ez a regiszterekben való elveszés is csak azért van, mert az x86-os assemblerek bénák (voltak?) Ha assembly-ben programozok, mibe van beleszólása a fordítónak?
- "Simán aliast adsz egy regiszternek." x86-os assembly-ben hogyan?
- "Vagy ha C-be ágyazott assembly, akkor lokális változók, s a fordító lefoglalja neked a regisztereket." Nem C-ben programozok, hanem assembly-ben.
- 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. Pedig belefér egy 4*4-es mátrix, x64-en kívül is (4*32bit*8 vagy 2*64*8). A memória kihagyásával történő transzponálás miben/hogyan működne optimálisan? Komolyan kérdem, register-ek közti átrendezést, több (4?) írt regiszterrel mi támogat?
- Nincs beépített shuffle, meg maszkolás stb. Mi az, hogy beépített?
- 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. Bővebben?
[ Szerkesztve ]
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies
"Fordított bitszámozás? Itt little-endianra gondolsz?"
Nem. Hanem az MSB a 0., és az LSB a 31. Szal balról jobbra sorszámozzák.
(Bár a doksik szerint ez régi IBM standard. Csak nem tudom, honnan is szedték. Procit régebben ugye nem terveztek egyedül, csak talán egyszerűbb IC-ket, pl. perifériaillesztőket, ilyesmit. Érdekes onnan átemelni ilyesmit a procik világába. Azt sem értem, a Motorola hogy hagyhatta...)
"Egyébként én big-endian hívő vagyok."
Találgass, én hogy vagyok ezzel. Ez a logikus, csak ugye egy 8 bites proci 16 bites kiterjesztésének... stb. szükségszerűen little-endian.
Egyébként a G5 előtti PowerPC-ken egy bittel bármikor át lehetett kapcsolni.
[ Szerkesztve ]
-
[ Szerkesztve ]
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.
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
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 ]
Az AMD úgy jön ide, hogy az intelen semmiféle nyomás nincs, az amd részéről, így egy csomó szabad projektje fut pl. Larrabee.
Ki mondta, hogy egyből integrálja a két vonalat(x86+Larrabee)?
Az viszont biztos, hogy előbb-utóbb megteszi és akkor a cellnek még halvány esélye sem lesz.
Sokkal többet tudok, mint gondolnád ![;]](/dl/s/v1.gif)
, nem véletlen a névválszatás sem
A Power vonalnak jelenleg egyetlen ütközés pontja van az intellel az pedig az itanium, de ez is inkább az IBM-HP harc és igazából a Power5/6-nak jelenleg nem ellenfél az itanium.
Ez nem csak a teljesítményre igaz, hanem a szolgáltatásokra is.
Csupán azért nem lehet lesöpörni, mert az intel áll mögötte és képes finanszírozni egyéb bevételekből az itanium fejlesztését és a piac egy része hisz neki, főleg az média.
A konzolok világát az IBM uralja, a pc-nél pedig pont fordítva.
Power
Ha lenne nyomás, akkor is több projekt futna...
Arról van szó, hogy talán később sem kell összehozni őket, ha a Larrabee egyedül is el tudja vinni a sima x86/x64 kódot is.
Én nem lennék benne olyan biztos, hogy a Larrabee kapásból (akár összehozva szokásos x86 CPU-val, akár nem) elsöpörné a Cellt. Mire kijön, már nem az 1 PPE + 8 SPE-s Cellel kell versenyeznie...
Névválasztás apropója? Azt utálod a legjobban?
Ismét megfeledkezel a szerverekről és a szuperszámítógépekről. Csak egy név: BlueGene... Top500-as listából a rendszerek majdnem felét az IBM adja.
