IBM bude licencovat architekturu POWER

IBM se rozhodlo inspirovat se úspěchem ARMu a začít technologii POWER (PowerPC) licencovat pro výrobu vlastních čipů. Tento nápad se zatím líbil Nvidii, která by mohla kombinovat svá GPU s CPU POWER. Otázkou je, jestli není tak trochu pozdě.

7.8.2013 15:39 | Luboš Doležel (Doli) | IT novinky

Komentáře

[2X4B-523P]

pozdě není nikdy, x86 je také není kdovíjaká novinka, jen je IMHO obalená tak, aby stíhala... navíc spousta lidí nemá x86 zrovna v lásce a mají k tomu své důvody... HW a SW diverzitě zdar

[Ovocníček]

Mnoho lidí nemá x86 v lásce, ale [oprava:] k tomu většinou žádné reálné důvody nemají ;)

Schválně, kolik procent slašdotářů nebo místních píše kompilátory nebo kód v asembléru?

[danaketh]

Ono je dneska moderní kdejakou zanedbatelnou minoritu označovat jako "spousta lidí", "množství zákazníků", "významné procento trhu" nebo "širokou veřejnost". Když se tomu chvíli věnuješ tak zjistíš, že jich je pět a vedou vzrušený debaty o sociální rovnosti někde v garáži nad krabicí vína za 12,- :)

[marek_hb]

[Peter Golis]

Za 12 CZK sa víno nedá zohnať. A pokiaľ si myslíš že fermentovaný jablčný nápoj je víno, tak si k nim do tej garáže kľudne prisadni.

[Ovocníček]

Já myslím že už i to čučo je o dost dražší... kdysi jsem někde viděl krabicák za 19,90 a to jsem si říkal, "ty vole, co tohle je". předtím obvykle krabice stály 35-40 litr. Ale inflace je svině, takže od té doby to určitě je jenom horší :D

[Peter Golis]

To vieš, keď sa pán odborník hanbí za stretávky v požičanej garáži a mieša si v krabici alpský ryzling, tak je to ťažké. Koľko že stojí liter octu a jedna alpa?

[danaketh]

Ale dá. Nedávno jsem takový kvalitní "vinařský" produkt viděl v Globusu. Ale netroufám si odhadovat z čeho je to vlastně vyrobené. Kolem vína to ale IMO akorát vezli. A tipuju, že na krabici bude někde drobným písmem napsáno "vinný výrobek" nebo něco takovýho, protože na označení "víno" to nesplňuje požadavky. Ale ty hrozny na obalu udělaj svoje.

[Peter Golis]

Víno sa robí z révy a tam sa človek naozaj nezmestí do tej ceny. Nie každý kvasený ovocný nápoj sa volá víno, rovnako ako nie každý roztierateľný tuk sa volá maslo.

[Grunt]

Naprosto největší odborníci na víno: Pražáci a Bratislaváci. Tam jim toho totiž roste… Znám lidi co by za víno v životě nedali ani korunu a zrovna kyselinu citrónovou s vodou rozhodně nepijí.

[xxxs]

k tym bratislavakom. hrozno sa tu nepretrzite pestuje este od cias keltov. rimania to uz rozbehli celkom slusne a mestska cast raca je aj teraz znama vinohradnicka oblast.

[Grunt]

Jak jsem to myslel určitě víš, víc to potřeba rozebírat není…

[Peter Golis]

Áno, myslel si to bez uváženia. Nevieš sa zmieriť s tým, že vinohrady existujú aj za hranicou Tvojho chotára. Ale, je to tak. Rovnako ako že zem nie je plochá.

[Grunt]

Áno, myslel si to bez uváženia. Nevieš sa zmieriť s tým, že vinohrady existujú aj za hranicou Tvojho chotára.

Ne, to jsem nemyslel. Myslel jsem to tak, že obézní Pražáci a Bratislaváci z pěkného baravného baráčku na předměstí s nadměrným egem co to kupují a chlastají po kartonech ví o víně ještě věští hovno než já (a že já toho vim), především pak o jeho ceně. Tak jsem to myslel, pokud to nebylo jasné.

[Peter Golis]

Rača je predmestie Bratislavy a je to aj zároveň uznávaná vinohradnícka oblasť.

Takže, áno. Posudzuješ to, o čom nič nevieš. A trváš na tom že sa potrebuješ zosmiešniť kôli Tvojej neznalosti.

[Grunt]

Ty si z Rače?

[Peter Golis]

Máš problém s vínom alebo bez neho?

[Ovocníček]

Mimochodem dřív se vinná réva pěstovala všude možné, včetně té Prahy (je koneckonců poměrně nízko). Stačí se jen podívat na všechna ta místní jména, která pocházejí od vinařských usedlostí (o Vinohradech asi nemluvě)!

Slyšel jsem, že historicky byly snad dokonce vinohrady na jižních terasách zámku v Českým Krumlově (nadm. v. ~500 m, předhůří Šumavy...), což už je docela sranda. Ale asi to nebyla nějak významná produkce.

[pavlix]

V pražských Vršovicích je docela pěkná vinice. Doporučuju ochutnat zdejší víno dřív než řekneš, že se nedá pít ;).

[Grunt]

A pavlix zavítal do diskuse. No tak to se asi začnu pomalu balit abych nebyl ubit argumenty…

[Michal Vyskočil]

No tak těch pár hektarů zbytků vinic v Praze je vážně docela zanedbatelné číslo.

[pavlix]

Co z toho vyplývá?

[little.owl]

Z toho vyplyva, ze tva vinice v Praze v kvetinaci na balkone se nepocita, stejne jako tvuji vinny sklipek v X-tem patre .

[pavlix]

Chápu, že si to tak někteří „znalci“ představují ;).

[little.owl]

Dalsi hezka je treba hned vedlo ZOO, Vinice sv. Klary.

[deda.jabko]

Ja se hlasim. :-]

Pruser s diverzitou je, ze to bude znamenat vic prace, resp. programu, ktere funguji jenom nekde. Ono se staci podivat, jak je to treba s podporou ARMu nebo SPARCu u veci, ktere pouzivaji JIT preklad.

[Ivan]

Zatim, to neni tak hrozny. Portfolio aplikaci pro AIX je "omezene" uz mnoho let. Pouziva se vice-mene jen pro databaze(DB2,Informix,Oraxle), SAP a WebSphere. Vetsine korporaci to staci, kdyz jim na tom bezi core systemy. Hlavne ze ma IBM vlastni Javu.

Par programu jsem pro AIX portoval, a nebylo to nijak hrozny. I kdyz to bylo vice prace nez portovani pro Solaris.

IBM doplaci na to ze leta odminala prodavat produkty "normalnim" lidem. Kdysi nabizela FreeScale nejake desky s PowerPC, ale i ty byly priserne drahe. Problem PowerPC procesuru byl a je v tom, ze je to pro normalni smrtelniky nedosazitelne. A ve firmach kde rozhoduji normalni smrtelci si tom pak nekupuji.

[miky]

To je velka korporace, ktera je zvykla zdimat vladu USA a velke korporace. Cena tech chipu z vyrobniho hlediska je srovnatelna s "konkurenci", jenze velka modra na jeden chip da cenu 10x vetsi nez jsou vyrobni naklady a k tomu cca 15x nasobek za aktivaci... Jenze, kdyby to pustili do sveta za normalni penize, z ceho by platili firemni akce a vanocni vecirky :)))

btw. mel jsme moznost si sahnout na par enterprise stroju (HP, SUN (blahe pameti) a IBM). power 5 jeste byla srovnatelna s konkurenci, 5+ uz byl mirny pokrok a nastupem power 6 a pak 7 mi prislo, ze hosi vytvorili litou selmu, ktera nema konkurenci...

[vlastikroot]

Realny duvod je, ze x86 je hromada svinstva desitky let stareho. Navic je to technologie prosazena marketingem, ne svoji technickou dokonalosti.

[Ovocníček]

No to tedy reálný důvod fakt není.

Reálné je, že jsou to procesory, která mají momentálně nejvyšší výkon v rozumné cenové relaci (čímž myslím, že možná někde seženete nějaká big iron čip, co bude v některých úlohách možná rychlejší, ale za pětimístnou dolarovou sumu a vůbec to prakticky nebude použitelné).

Cenově jsou (jakožto PC hardware) taky v podstatě nejdostupnější. Ano, můžete si koupit RPi, ale jde to srovnávat? To tedy ne.

Jejich spotřeba (v poměru k výkonu) je taky sakra dobrá (u Intelu, tedy), mají spoustu šikovných SIMD rozšíření, jejich veliký a velmi dobře kompatibilní ekosystém (kdežto naopak ARM... no škoda mluvit, jak standardizované to všechno je - co SoC, to out-of-tree patchset pro jádro, se dá skoro říct.)

Takže mi už docela lezou krkem frikulíní, co na to musí nadávat aby byli cool, a přitom vůbec netuší o čem je řeč. Ale jo, proč nežít v krásném snu, kde stačí aby něco bylo RISC a dostatečně obskurní, a hned to jistě nabízí takový výkon a všechno, že z toho podruhé sestoupí na zem chudák Kristus.

[mirec]

X86 je blbosť. SIMD je blbosť. Na stole mám ARM, ktorý z SD bootuje 3s do grafiky s OpenGL ES2 akceleráciou. Beh aplikácií je fakt plynulý. Ako náhrada SIMD sa používa OpenCL na grafike (a to dáva výrazne lepšie výsledky než nejaké smiešne X86). Nebyť skriplenej grafiky (ktorá je zrejme vektorový procesor) pravdepodobne by raspberry drvilo x86. O elegancii thumb2 oproti x86 radšej ani nebudem písať.

[Ovocníček]

Náhrada SIMD OpenCl na grafice? Hahaha!

No ale jak čtu ten zbytek, tak tomu fakt rozumíte od hlavy až k patě, nejen tomu, co jsou SIMD instrukce a jak nahraditelné jsou offloadem kódu na grafiku :>

[vlastikroot]

No, na nektery veci je mnohem lepsi OpenCL nez SIMD. Ale dost lepsich ARMu ma nejakou vektorovou jednotku, treba NEON. V nekterych je DSP. Nevim, cim by byly SIMD instrukce x86 zvlastni

[Ovocníček]

Jo, ale programoval jste OpenCL? Je to naprosto PITA, kdežto nějaký SIMD asemblér je naprosto integrální součástí programu, bez závislostí na SDK a ovladačích (jo, program, jehož fungování závisí na tom, jak se vyspí grafické ovladače, to zní skvěle) a tak podobně.

Neon má pokud vím jen 128bitové vektory, Intel v tomto jde pořád vpřed (AVX/AVX2; za dva roky by měly přijít už i 512bitové operace - AVX-512). Co já vím, tak programátoři asambléru ho považují za povedený, ale x86 má asi přece jenom ten arzenál lepší.

[vlastikroot]

OpenCL je docela masakr, pravda ja radsi CUDA. Ale zatim jsem nenasel, na co by mi to bylo dobre, ani na to nemam poradne HW. Mnohem bliz mi je DSP nebo FPGA, nez grafarna. Na x86 udelat program, ktery vyuzije plne vsech schopnosti jakehokoli modelu procesoru je nadlidsky ukon. Uz jen ta detekce a asembler/intrisika pro MMX/SSE/SSE2 atd atd. Libilo by se mi neco jako Itanium jako koprocesor k ARMu

[Ivan]

Kdyz uz tak Altivec, aby to bylo k tematu, PowerPC melo tyhle veci mnohem drive. I kdyz kompilator od IBM ktery tyhle veci pouzit stoji opravdu nekrestansky penize.

[ed]

altivec vie pouzit kdejaky kompilator (rozumej: aj gcc). ak sa ale budeme bavit o autovektorizacii, tak tam je na tom llvm trocha lepsie ako gcc, u gcc to pokulhava, ale pracuje sa na tom, aby to s autovektorizaciou neslo aspon pomalsie, ako bez nej.

[little.owl]

OpenCL je docela masakr, pravda ja radsi CUDA.

CUDA je stejny shit a OpenCL je alespon portovatelny standard.

[gngl]

Jo, ale programoval jste OpenCL? Je to naprosto PITA

A co SPIR? Když si napíšete nebo seženete kompilátor vámi preferovaného jazyka s výstupem do SPIRu, tak se tomu v zásadě vyhnete. Stížnost na potřebu ovladačů je poněkud pokrytecká, protože třeba bez správného firmwaru na desce si ani neinicializujete řadič DRAM, takže se tomu stejně nevyhnete.

[Ovocníček]

No jo, ale BIOS, to je snad něco úplně jiného, než se spoléhat na grafické ovladače, což jsou v současnosti ty největší monstra mezi OVLy, navíc ty výkonné jsou uzavřené. A myslím, že většina vývojářů GPGPU aplikací s nějakým větším kódem ofloadovaným na GPU vám řekne, jaká je to hrůza - nekompatibilita mezi Intelem, AMD a nVidií, nekompatibilita mezi různými verzemi ovladačů a bugy bugy bugy. Odladit takovou aplikaci je co jsem viděl peklo, a určitě nemáte záruku, že se to nerozesere v příštím půlroce, až se něco změní v ovlech.

SPIR neznám, ale takovéhlemu řešení bych moc nevěřil. Nějaká takováhle automatizace je teoreticky hezká, ale naivní OpenCL kód je vám k ničemu. Když úlohu nezoptimalizujete ručně, tak asi často skončíte s něčím, co by rychleji běželo na jednojádrovém CPU.

[gngl]

SPIR neznám, ale takovéhlemu řešení bych moc nevěřil. Nějaká takováhle automatizace je teoreticky hezká, ale naivní OpenCL kód je vám k ničemu. Když úlohu nezoptimalizujete ručně, tak asi často skončíte s něčím, co by rychleji běželo na jednojádrovém CPU.

Člověk by řekl, že moderní kompilátory by si od vás zasloužily více lásky. (Ale já jsem možná zaujatý, protože "ruční optimalizace" nad rámec pečlivě vybraných primitivních operací děsně nenávidím.)

[little.owl]

Ale dost lepsich ARMu ma nejakou vektorovou jednotku, treba NEON.

Fajn, ale SSE*/AVX* je o neco dale.

V nekterych je DSP.

Nevim kolik jste delal projektu s hybridnimi SoC, ale casto je trapeni, ted bych preferoval vice stejnych jader.

[wtf]

neboj. to skonci, jak se ARM rozsiri, tak se na nej nabali vsechny HW a SW ficury a podpora kde ceho a ze 3s budes mit 3min za 30 let vyvoje jako na x86.

[nyan]

raspberry drvilo x86

x == 3 ? ten mozna

[little.owl]

OpenCL na grafike (a to dáva výrazne lepšie výsledky než nejaké smiešne X86)

Jste spadl z visne. Moznost pouziti OpenCL na realnych algoritmech je limitovana, ne kazdy algoritmus lze efektivne implementovat.

[pc2005]

kdežto naopak ARM... no škoda mluvit, jak standardizované to všechno je - co SoC, to out-of-tree patchset pro jádro, se dá skoro říct.

Porovnávej porovnatelné. SoC ARM má i periferie, se samotným x86 procesorem to porovnat nejde. Pokud se chceš aspoň přiblížit, tak porovnej SoC ARM s embedded x86 deskou. A abych pravdu řekl, tak ta tuna LPC/SuperIO čipů, kde jsou rozdíly i u jednoho výrobce taky není zrovna unifikovaná (z historie: export FDD signálů na LPT s nekompatibilitou DVOU! signálů (winbond/smsc), rychlost sériáku zamrzlá na 115200 (ITE)).

Taky nezapomínej na 386 linux aféru.

[Ovocníček]

SoC x86 má taky periférie. I neSoC, protože procesor bez čipsetu asi těžko, že? A přesto to v těch PC nedělá neplechu.

[pc2005]

Samotné moderní x86(-64) procesory i s grafickými jádry mají IMHO méně věcí než některé ARM SoC. Pokud se pro porovnání přibere x86 čipset (další čip na desce není system on chip), tak musíš porovnávat s ARM SoC, kde je třeba SATA nebo ethernet. Když se podívám do x86 konfiguráku jádra, tak tam je SATA/ethernet/apod. ovladačů nespočetně (ARM SoC má ale výhodu, že jádro tvoří podporu už přes ~20 let). Navíc ve věcech čipsetu pomáhá kernelu BIOS/UEFI, což na ARMu být nemusí.

[Conscript89]

Proto taky cekam az bude nejaky poradny arm system pro smrtelnika s UEFI (ne ovsem ten od MS na ktery si nedam jiny system nez Windows). Na to si asi ale pockam a pouzitelny bude nejspis az aarch64 :/

[ed]

ziadne UEFI tam pchat netreba. standard na toto uz existuje a niekde sa snad aj pouziva. vola sa to openbios a UEFI mu v niektorych ohladoch ako keby z oka vypadol. dovolim si zakonspirovat, ze sa nim intel nechal "inspirovat" namiesto toho, aby ho ako defakto standard prebrali tiez.

[Conscript89]

Openbios je snad jen na PowerPC ne? Jinde jsem ho jeste teda nevidel a na armu bude spis UEFI.

[Peter Golis]

Nejaký PPC mi tíško pracuje na stole a ten má veru OFI teda open firmware. Teda, tíško v ňom od výroby tiká niečo iné ako openbios. Už je to taký deduško počítač. Nedali mu do vienka bezolovnatú pájku, a tak pracuje spoľahlivo už roky rokúce.

[Ivan]

OpenBIOS? Neni to spis OpenFirmWare? Ten byl/je na AIXu, na Alpha a myslim ze i SPARC.

[Conscript89]

Mate pravdu, nejak se mi ty open veci pletou :)

[nyan]

Reálné je, že jsou to procesory, která mají momentálně nejvyšší výkon v rozumné cenové relaci

Pletes si procesory s architekturou. To ze ma Intel rychle CPU, nesouvisi s tim ze x86 (presneji 32bit cast) je sracka.

[Ovocníček]

No pozor... já říkám, praktické důvody. Realita je prostě taková, že ty procesory x86, bez ohledu na to, že je to údajně hrozná sračka, nemá 99,9 % lidí žádný racionální důvod nenávidět, což je to, proti čemu jsem se vymezoval.

IMHO ani ta architektura není tak hrozná. Lidi prostě budou vždycky nadávat na všechno, ale v těch ostatních procíkách/technologiích je taky humus, tak to prostě asi na světě chodí. Programátoři chtějí, aby se to všechno snadno programovalo a dělalo to věci zrovna podle jejich představ, ale přitom je to hardware - není sranda ho navrhnout a vyrobit, takže jak každý určitý procesor, tak samotná ISA musí podstupovat určité kompromisy. Puristi/kibicové/lidi co ví všechno pak třeba na určité omezení nebo opruz budou hrozně nadávat, ale ono to má obvykle nějaké praktické důvody.

A tyhle kompromisy se budou nacházet ve všech architekturách, takže si nepomůžete. Kdyby ty CPU navrhovali ty puristi a různí kibicové, aby to bylo všecko podle jejich představ, tak by zase vzniklo něco, co by se z toho křemíku nikdy nedalo levně udělat, výkon to ve finále mělo hroznej a spotřebu taky - protože by to prostě nebylo "optimalizované pro výrobu".

[deda.jabko]

IMHO ani ta architektura není tak hrozná.

Treba prace s pameti je desiva. U 8086 resili problem, jak na 16bitovem procesoru vyuzit vic pameti (a zachovat kompatibilitu s 8080), vymysleli segmentaci. U 286 je napadlo segmantaci vylepsit, aby zvladla jeste vic pameti a chraneny mod k tomu. U 386 zjistili, ze to je k nicemu a vymysleli strankovani. Takze segmentace pameti (i kdyz je u AMD64 zcasti ignorovana) kvuli zpetne kompatibilite strasi na x86 dodnes.

ISA obsahuje hromadu nepouzivanych instrukci (kremik navic), na druhou stranu diky vsemoznym extenzim se neda spolehnout na to, co v tom procesoru je. Do nedavna se de facto nedalo spolehnout ani na pritomnost SSE2.

[Luboš Doležel (Doli)]

Segmentace se teď používá pro TLS (na Linuxu segmentové registry gs/fs), takže to našlo využití aspoň tam.

[ed]

TLS funguje aj na platformach, ktore segmentaciu nemaju, takze to s tym vyuzitim asi az tak zhave nebude :)

[Ondrej 'SanTiago' Zajicek]

Do nedavna se de facto nedalo spolehnout ani na pritomnost SSE2.

To nejde porad - stale se bezne pouzivaji procesory bez SSE (napr. AMD Geode LX) a Debian AFAIK defaultne kompiluje pro x86 bez SSE.

[R]

Alebo AMD Athlon, ci Pentium 3. Napriek tomu nejaky debil v Adobe nastavil kompilaciu Flash na SSE2 a uz to tam asi nikto nevie vypnut...

[pc2005]

Historie se opakuje, já měl problém s non SSE Duronem a SSE driverem na grafiku.

[Ondrej 'SanTiago' Zajicek]

Koukam, ze v mem predchozim postu je drobny vyznamovy posun - mel jsem napsat spis 'stale se bezne vyrabeji a prodavaji' nez jen 'pouzivaji'.

[Ovocníček]

No, jestli tohle někomu vadí, tak s Neon u ARM je to ještě horší. Ten neměla ještě Tegra 2. A to je prosím Cortex A9 - u této architektury byl totiž Neon jen volitelný.

V multimediálním softwaru, který SIMD hodně potřebuje, se to řeší detekcí podporovaných instrukcí.

[JoHnY]

Tegra 2 bylo snad jedinej Cortex A9 bez Neonu a taky peknej kram.

[Grunt]

Co si budeme povídat. Ono dokud lidi nevezmou do ruk kovadlinu a nezačnou si ty procesory sami kutat, tak se v tom ty sračky budou furt udržovat, na architektuře naprosto nezávisle. Někdy bych rád zkusil tohle.

[pc2005]

místních píše kompilátory nebo kód v asembléru

Já, díkybohu ne na x86 (jako obecný program ještě ujde, hrál jsem si s vlastním "bootloaderem", ale CPL0 je humus).

[nyan]

Mnoho lidí nemá x86 v lásce, ale [oprava:] k tomu většinou žádné reálné důvody nemají ;)

Treba 1) registru to ma jako CR poctivych politiku, a 2) instrukce pracuji nad fixovanymi registry. Tudiz 1/4 vyslednych instrukci nedelaji uzitecnou praci, ale jen presouvaj registre, aby je pristi ins mela v spravnych registrech. A ano, vim ze existuje spousta workaroundu (v CPU) aby to bylo rychlejsi, ale zbytecne to komplikuje kod kompilatoru i navrh CPU. Takze ano je to sracka, a ty duvody jsou realne.

[Ovocníček]

[opakuji...] Reálné důvody pro ty, kdo zrovna nepíší kompilátor. Páč tohle reálné důvody pro 99.9% lidí nejsou. A těch registrů už je tam v 64bitové verzi, ehm je rok 2013, taky dost (16 zas tak málo není + dneska máte PRF, takže se to přehazování mezi nimi a pamětí moc neprojeví)...

[Luboš Doležel (Doli)]

Jen nechápu, proč jich tam rovnou nedali ještě víc. PPC jich má od začátku 32 a místo aby to při příchodu x86-64 dohnali, tak zase šetří.

[Ovocníček]

Četl jsem někde, že to prostě byla otázka přínosů a nákladů. Na základě nějaké analýzy si spočítali, že největší užitek je ze zvýšení na 16, na 32 už to task slavné není (pochopitelně je možné, že to spočítali špatně).

Nemám úplně představu, jak je to tam signalizováno, ale asi by víc registrů už natahovalo délku kódu (kvůli delším identifikátorům) a množství dat, které se musí po procesoru přenášet. Pouhé zdvojnásobení by sice na první pohled moc velký rozdíl dělat nemělo, ale co já vím, třeba to tak zrovna vycházelo. Jinak to jsou jenom obecné registry, jsou tam i další + registry FPU. SIMD instrukce mají také vlastní registry (XMM, YMM, budou ZMM).

[__dark__]

Asi tak, pomoci 1 byte na instrukci pridali dalsich 8 gp a xmm registru, takze kdyz to sectu - 16x Gp, 8x Mmx, a 16x Xmm, coz je celkem 128+64+256 bytu pameti jen v registrech. Kdyz jsem psal AsmJit tak mi ta architektura zase tak strasna neprisla. Kdyby tu nebyla x86, tak by si lidi stezovali zase na neco jineho.

[Ovocníček]

O tu celkovou velikost samotnou asi tolik nejde, protože dneska ty procesory mají oproti architektonickému počtu registrů větší počet fyzických registrů, které různě přejmenovávají, aby se to nemuselo přenášet do paměti a zpět. Bude to spíš o spotřebě a o té velikosti kódu (protože instrukční cache je malá, takže menší kód = větší výkon).

[Ivan]

Na PowerPC je to tak, ze cast registru(asi 8) se spotrebuje na ABI - parametry se predavaji v registrech. Vsechny instrukce maji stejnou delku. Je to ale vyvazeno tim, ze pouze 4 instrukce(load, store, syscal, a neco divnyho) pracuji s pameti. Ostatni instrukce pouzivaji jako operand pouze registry.

Kdyz k tomu prictu, ze XCOFF binarky knihoven obsahuji jak 32bit tak 64bit symboly, tak z toho vychazi, ze binarky pro AIX jsou dost velke.

[mirec]

U X86 to práve nekomplikuje návrh kompilátoru pretože o správne vykonanie inštrukcií v pipeline sa stará priamo CPU (rôzne optimalizácie s tým však môžu rátať, ale nie je to povinné, takže jednoduchý kompilátor bez optimalizácii sa dá namlátiť relatívne rýchlo). U ARM musí človek rátať s pevnou dĺžkou, posunutým PC a usporiadavať poradie inštrukcií tak aby sa neovplyvňovali a zároveň sa využila pipeline samotný kompilátor. Na druhej strane pipeline je výrazne kratšia a nekomplikuje to tak návrh CPU ako superskalárne monštrá x86.

[little.owl]

[uleva] Vsechny nove SoC stoji za kosoctverec.* [/uleva]

* Dusevni rozpolozeni po nahledu do chaotickeho Technical Reference Manual noveho prototypu SoC majiciho 7100 stran.

[dustin]

Kolik stran má komínek srovnatelně detailních manuálů všech prvků, které jsou integrovaného do toho SoCu?

[little.owl]

Souvisejici HW moduly dokumentovane jinde - GPU, Video/Image Accelerator, etc. - mohou mit tak okolo dalsich 3000 stran (GPU je jako obvykle osekana); dokumentaci generickych jader ARMs a DSP nepocitam.

Kdyby to ti kosoctvercove alespon rozdelili na mensi casti, takhle nad tim sifrovanym pdf kucka i Adobe Reader na desktopovem i7.

[dustin]

Budeš si to muset nařezat sám :)

[little.owl]

To bych se k tomu musel nejak rozumne dostat - je to na stroji, ktery neadministrujeme, bez site, nemuzeme nic instalovat a logujem se pres hw klic a ctecku otistu - asi tak 80% pravdepodobnost uspechu.

Mohu nafotit 7100 screenshotu telefonem a pak si to usporadat.

[dumblob]

je to na stroji, ktery neadministrujeme, bez site, nemuzeme nic instalovat a logujem se pres hw klic a ctecku otistu - asi tak 80% pravdepodobnost uspechu.

Uz pomalu zacinam chapat jak moc dulezite je NDA pro manazery.

Mohu nafotit 7100 screenshotu telefonem a pak si to usporadat.

Nejdelsi PDF jsem cetl s cca 2500 stranami a byla to hruza (ackoliv to bylo pomerne velkym pismem a dobre, misty az prilis, clenene ve stylu wiki). 7100 stran ti vsak opravdu nezavidim.

[dustin]

Tohle "zabezpečení" je kvůli tomu NDA dokumentu?

[little.owl]

Tak, nesmi se dostat kopie ven a pristup maji jen autorizovani lide.

[pc2005]

Takže tedy Brighton?

[little.owl]

Pro me za me, klidne, pak mi to prosim poslete narezane.

[pc2005]

[kogolo]

zpravicka i diskuze se mi zda jako dobry namet na clanek, nebo serial. kdyz vezmem treba kde mohla byt motorola atd.. radbych si neco takoveho precetl...